tmsr - Log 2018-11-19

mircea_popescu: BingoBoingo not bad, though i prefer the fully formatted style, with dates etc, like in http://trilema.com/category/bitcoin/ or http://trilema.com/2017/06/ etc.

ben_vulpes: mod6: why does the net change in pizarro's cash account for august not equal the difference between the sum of incoming and outgoing cash transactions? ☟︎

ben_vulpes: BingoBoingo: why does mod6's ledger show a transaction for 0.1 btc to you on august 12th and then back from you on august 17th? it doesn't affect the accounting, but i am perplexed as you both stated that your ledgers in these shared notes contained all of your pizarro transactions with noted exceptions that do not include that transaction. ☟︎

ben_vulpes: amend that question to include the detail that *your* submitted ledger does not contain either of those transactions.

ben_vulpes: asciilifeform, mod6, BingoBoingo: http://p.bvulpes.com/pastes/tHcxD/?raw=true (these missives have not been encrypted, only signed. if any would like to read, please do.) ☟︎☟︎

ben_vulpes: asciilifeform: i believe this report settles the reported discrepancies. i will have to respond to queries asynchronously, as i'm traveling for the next week.

ben_vulpes: asciilifeform: i've sketched out a set of tables that could hold all pizarro data accounting data and generate statements; the only remaining puzzlers are modeling subscriptions, prepay, and asset depreciation. would you like me to complete the design, put sql to disk and turn this into an accounting spreadsheet for pizarro? ☟︎

bvt: mircea_popescu: i understand that empty genesis (well, it's not precisely empty, there is a manifest file) is suboptimal, however: ☟︎

bvt: 1. x86 and arm trees will diverge pretty much from the start, i can't see how anything useful and complete can be packed into genesis.

bvt: 2. i seem to remember but can't find right now a discussion (around time spyked published adalisp) that making such a genesis should be ok. perhaps i am confused about the context of that discussion and did something stupid.

mircea_popescu: i mean, it certainly has the virtue of signalling, "Hey guise, i intend to do this" sorta thing

diana_coman: phf, I wanted to sign your vtools patches but I realised that they are using sha so I don't really know: do you plan to regrind them with keccak?

diana_coman: bvt, while I don't see a big problem per se with an empty genesis, the question for your specific situation is why glue together 2 trees if they diverge right from the start anyway?

bvt: ok, so the discussion seems to be here: http://btcbase.org/log/2018-06-25#1829429 , and unlike me, spyked did publish the code. ☝︎

a111: Logged on 2018-06-25 16:40 mircea_popescu: spyked> I think there's great benefit in the ffa chapter-based approach << that ~started with a genesis~.

bvt: i want the platform-specific branches to be glued together because API for users should be the same in all of them. so that user can press a branch for aarch64 or x86 without changing anything in his code.

diana_coman: bvt, that sounds like you want to start then the tree with ..the API? otherwise at any rate, the user CAN use the same API with whatever provides it, no? ☟︎

mircea_popescu: experience kinda seems to indicate trying to have the same model for two things is a recipe for tears in this "industry" of apes and aping, but then again... man gotta try. ☟︎

deedbot: http://bimbo.club/?p=83 << Bimbo.Club - TMSR Log Summary - 11/05/2018

deedbot: http://trilema.com/2018/the-keks-of-all-time/ << Trilema - The keks of all time...

asciilifeform: http://btcbase.org/log/2018-11-19#1873558 << got it; loox like it is ready to mechanize, ben_vulpes ..? ☝︎

a111: Logged on 2018-11-19 06:31 ben_vulpes: asciilifeform, mod6, BingoBoingo: http://p.bvulpes.com/pastes/tHcxD/?raw=true (these missives have not been encrypted, only signed. if any would like to read, please do.)

a111: Logged on 2018-11-19 07:09 ben_vulpes: asciilifeform: i've sketched out a set of tables that could hold all pizarro data accounting data and generate statements; the only remaining puzzlers are modeling subscriptions, prepay, and asset depreciation. would you like me to complete the design, put sql to disk and turn this into an accounting spreadsheet for pizarro?

asciilifeform: ben_vulpes: i assumed the worst, that asciilifeform would have to somehow fit whole thing on his already packed conveyor.

asciilifeform: http://btcbase.org/log/2018-11-19#1873561 << here is where i admit that i dun see wtf is the point of an empty genesis ☝︎☟︎

a111: Logged on 2018-11-19 07:54 bvt: mircea_popescu: i understand that empty genesis (well, it's not precisely empty, there is a manifest file) is suboptimal, however:

asciilifeform: genesis, in my conception, oughta at the very least set the flavour of a tree, with ~some~ semblance of a working item

asciilifeform: ( e.g. ffa genesis, is very small, but contained all of the basic fundamental moving parts for simple arithm )

mod6: http://btcbase.org/log/2018-11-19#1873558 << Thanks for the audit report ben_vulpes. Looks like you figured out this (http://btcbase.org/log/2018-11-19#1873555) from your report notes. ☝︎☝︎

a111: Logged on 2018-11-19 05:06 ben_vulpes: mod6: why does the net change in pizarro's cash account for august not equal the difference between the sum of incoming and outgoing cash transactions?

mod6: http://btcbase.org/log/2018-11-19#1873556 << As for this, BingoBoingo began doing a cut-down of the notes file, so more recent editions have not had older-months notes contained. I have went back and found the notes around the 0.1 BTC sent between us from august. Here is that specific snippit: http://p.bvulpes.com/pastes/CEgRj/?raw=true ☝︎

a111: Logged on 2018-11-19 05:30 ben_vulpes: BingoBoingo: why does mod6's ledger show a transaction for 0.1 btc to you on august 12th and then back from you on august 17th? it doesn't affect the accounting, but i am perplexed as you both stated that your ledgers in these shared notes contained all of your pizarro transactions with noted exceptions that do not include that transaction.

mod6: ben_vulpes: In case you are curious, here is the full notes file from the end of august, just for posterity: http://p.bvulpes.com/pastes/5ZN91/?raw=true

mod6: I won't speak for BingoBoingo as to why his ledger copy does not show the 0.1 BTC sent from me to him, and then back from him to me. I'll let him speak to that.

asciilifeform: http://btcbase.org/log/2018-11-18#1873480 << this is entirely ok, diana_coman , there is not a burning hurry ( tho i expect that anybody who intends on firing ffa on battlefield will first take the time to properly eat it ) ☝︎

a111: Logged on 2018-11-18 20:52 diana_coman: http://btcbase.org/log/2018-11-18#1873291 - noted and added to the list though it might still take some time to get up to speed with ffa again

asciilifeform: mod6: errything well, ( tho asciilifeform as always during weekdays is knee deep in heathen rubbish )

mod6: Ah, ok BingoBoingo. Then that'd be it, since the 0.1 BTC back and forth took place in mid-August.

asciilifeform: BingoBoingo: ftr i still dun have anything like a working hypothesis re why the miners let segshitness live for as long as it has

asciilifeform: tho i think mircea_popescu had one, iirc it was 'they're letting the sow fatten for table', approx

asciilifeform: anybody recall whether there's a handy gauge somewhere re just how fat is the sow presently ? ( it ain't particularly hard to calculate , simply add up the coinz presently sitting in 'anyone-spends' )

a111: Logged on 2017-08-24 14:23 mircea_popescu: http://btcbase.org/log/2017-08-24#1702759 << eventually this will necessarily happen, yes. "segwit" transactions are stored on the bitcoin network as "anyone can spend", so eventually miners will unroll the segwit chain. how soon is not easily predicted (which is why the idea is stupid/usg-like, introduces impredictability in the currency)

a111: Logged on 2016-11-07 18:26 mircea_popescu: well, it slowly builds, until the miners defect.

a111: Logged on 2016-11-07 18:27 mircea_popescu: im sure nobody had the sense to create a "total payout to defecting miners" watch, because hey, they're "developers" not thinkers.

a111: 10 results for "prikoke", http://btcbase.org/log-search?q=prikoke

asciilifeform: lobbes: it's a riff on h. c. andersen ( who prolly lifted it from yet-elsewhere, i dun immediately recall from where )

deedbot: http://qntra.net/2018/11/pantsuit-lolsuit-against-russia-stumped-by-sovereign-immunity/ << Qntra - Pantsuit Lolsuit Against Russia Stumped By Sovereign Immunity

bvt: http://btcbase.org/log/2018-11-19#1873573 << i will have to think more about vtree organization. if i use api as the foundation for the tree, adding new system calls would cause regrind; in this case, the api should be complete from day one. ☝︎☟︎

a111: Logged on 2018-11-19 11:46 diana_coman: bvt, that sounds like you want to start then the tree with ..the API? otherwise at any rate, the user CAN use the same API with whatever provides it, no?

bvt: otoh, if system call asm packages are at the tree foundation, the api uniformity will be enforced by convetion only, and the branches will diverge right after genesis. ☟︎

diana_coman: bvt, from experience I can tell you that "complete from day one" is not likely to ever happen

diana_coman: the only case in which such a thing makes sense is if it's already a fixed /known /set in stone set

bvt: yes, i can definitely see that. scope of the tree must be fixed at the moment of creation. which is not necessarily a bad thing.

bvt: http://btcbase.org/log/2018-11-19#1873575 << this is why i'd like to work on struct stat (well, it is also required for mmap): fairly complex structure, which differs across architectures. ☝︎

a111: Logged on 2018-11-19 11:50 mircea_popescu: experience kinda seems to indicate trying to have the same model for two things is a recipe for tears in this "industry" of apes and aping, but then again... man gotta try.

bvt: i hope that for tmsr.os most of these things will become unnecessary; lower levels of libc/libada are not the right place to fix the underlying problem. ☟︎

diana_coman: bvt, precisely because it can't be fully clear in advance I'd suggest to choose the more flexible v-structure rather than something with set in stone requirements (such as API as root of the v tree sort of thing); this is NOT to say or guarantee you won't regrind but simply to not make ~surely needed

diana_coman: regrinds are not evil or anything of the sort but they do have a cost ; and if you get others to sign your patches, the cost increases since you lose the original signatures basically

diana_coman: so if you are not sure, I'd even keep the trees separately, I still don't quite see the problem with this (the benefit being that it doesn't force you to decide NOW on something you don't yet ...know)

diana_coman: keeping the trees in sync is probably cheaper than regrinding the whole thing anyway; and if /when it's not, then...regrind it as a single tree and that's that

bvt: i totally agree with all these points. tree diverging after empty genesis is separate enough in my view.

bvt: http://btcbase.org/log/2018-11-19#1873583 << this is unfortunate, i won't have possibility to work on this code in coming days; there will be a vtree stump for ~2 weeks. ☝︎

a111: Logged on 2018-11-19 15:18 asciilifeform: http://btcbase.org/log/2018-11-19#1873561 << here is where i admit that i dun see wtf is the point of an empty genesis

a111: Logged on 2018-11-19 20:45 bvt: http://btcbase.org/log/2018-11-19#1873573 << i will have to think more about vtree organization. if i use api as the foundation for the tree, adding new system calls would cause regrind; in this case, the api should be complete from day one.

asciilifeform: i've added all kindsa 'new api' in ffa, but the only regrind was when we took up new hash type for vtrons

asciilifeform: http://btcbase.org/log/2018-11-19#1873641 << entirely agrees with my pov, which is why i had the .c in udp lib ( http://www.loper-os.org/?p=2557 ) instead of five kilometres of 'let's try to parse the c struct of 17 diff cpus in ada' ☝︎

a111: Logged on 2018-11-19 20:52 bvt: i hope that for tmsr.os most of these things will become unnecessary; lower levels of libc/libada are not the right place to fix the underlying problem.

asciilifeform: imho the minimal .c glue is actually The Right Thing while we're still stuck on unix

diana_coman: asciilifeform, in my understanding he wanted to cement "common api" hence possibly root since that's the only common part for the 2 trees, hence "regrind" if new (because not in root etc)

asciilifeform: diana_coman: consider, if i'd done 'api first' for udp, would have ended up with ~same thing as ave1's hairball, i.e. 'just like gnat.sockets but maybe slightly less sad'

asciilifeform: it is quite impossible to say entirely in advance what api for glue layer on buncha unix garbage, will be, until fully grasped at least the outer surface of said garbage

bvt: http://btcbase.org/log/2018-11-19#1873650 << well, if i do common part (api) first, then diverging system-specific branches, i still could add new functionality on top of *each* of these branches. i don't like this option. ☝︎

a111: Logged on 2018-11-19 21:21 asciilifeform: http://btcbase.org/log/2018-11-19#1873629 << waiiiwaaaat ?!

bvt: alternatively, i could add new functions at common tree part if i don't touch any files included in later vpatches (so adding entries to manifest would be not possible). seems like some quite unnatural acrobatics to me. ☟︎

bvt: but i would agree that one's understanding of vtronics is determined by ones toposorter implementation.

asciilifeform: bvt: when you absolutely must publish mutually-exclusive variants of a thing, they oughta be v leaves, yes

asciilifeform: ( and if you extend on one such, and want to propagate into the others, then must regrind -- but strictly the piece in question ) ☟︎

a111: 5 results for "ifdefism", http://btcbase.org/log-search?q=ifdefism

asciilifeform: ^ the heathen barbarism that goes counter to this formulation, that we're thankfully rid of

asciilifeform: http://btcbase.org/log/2018-11-19#1873666 << much of what seems to n00bs as 'unnatural acrobatics' in vtronics is in fact the actual and inevitable cost of writing proggies ~honestly~ -- i.e. without pretending, as the heathens do, that 'i only changed this one little thing, whatddayamean it's a new program now' ☝︎

a111: Logged on 2018-11-19 21:44 bvt: alternatively, i could add new functions at common tree part if i don't touch any files included in later vpatches (so adding entries to manifest would be not possible). seems like some quite unnatural acrobatics to me.

asciilifeform: arguably v is a labour-saving device ~specifically for readers~, rather than writers, of programs -- if we were passing signed tarballs around, as we did prior to v, reader would be stuck determining exactly what changed, after manually verifying sig. ☟︎

asciilifeform: v makes it possible to sign a compartmentalized change , so reader is not stuck having to manually diff contents of signed_foo.today.tar.gz against signed_foo.tomorrow.tar.gz to see where the changes were. but what it deliberately does ~not~ do is to enable the pretense ( carried on in git & other heathen abominations ) that a proggy where something semantically upstream of $place were changed, is ~same~ proggy ~but for $place~ .

asciilifeform: the 'one little thing' is only 'little' when ~nothing depends on it~ -- i.e. is an extension of a leaf node, graph-theoretically speaking

diana_coman: bvt> http://btcbase.org/log/2018-11-19#1873650 << well, if i do common part (api) first, then diverging system-specific branches, i still could add new functionality on top of *each* of these branches. i don't like this option. -> perhaps unsurprisingly, the part that one doesn't like is however actually correct i.e. yes, you'll have to maintain the two separately if they are separate; hence my original "they are 2 trees" - because that's ☝︎☟︎

a111: Logged on 2018-11-19 21:21 asciilifeform: http://btcbase.org/log/2018-11-19#1873629 << waiiiwaaaat ?!

asciilifeform: if it is an item which conceivably affects the meaning of other text in unpredictable ways, then the patch must reflect this ( and we get 'reground' code. )

asciilifeform: diana_coman has it ( i'm expanding pedantically specifically for n00bs, but same point )

asciilifeform: to put it in mircea_popescuine terminology -- the scenario that v makes specifically and rightfully impossible is 'hey, i changed 'wife' to 'dog' in your marriage contract, but yer still just as married, you signed all the downstreams'

asciilifeform: bvt: it's in fact exactly the same thing that e.g. bitcoin does -- you cannot go back and flip a bit in block 100, and expect to be on the same chain as other folx, it'll correctly invalidate 101--present from your node's pov ( and your entire existence from other's pov )

asciilifeform: v is just about exactly same thing as bitcoin's chain, with the difference that it seals with manually-crafted operator signatures, rather than 'proof of work' gymnastics

asciilifeform: bvt: if you understand why bitcoin does not tolerate 'yes i'm on the same chain as you! except that i flipped a single bit in block 100, and really, honestly, nuffin ever depended on the tx where i flipped it!' -- you will also understand why v does not tolerate this either ☟︎

asciilifeform: the fact that it feels to noobs like 'unnatural acrobatics' is an artifact of writer suddenly having to pay that actual cost of the complexity inflicted on reader. and yes folx whined, just like in ex-ussr folx whined when they started having to pay for mains current . ☟︎☟︎

bvt: http://btcbase.org/log/2018-11-19#1873678 << what i did not like was following: specifically going for 'api at the tree root' variant, and then bolting on new (platform-independent) apis later. ☝︎

a111: Logged on 2018-11-19 22:42 diana_coman: bvt> http://btcbase.org/log/2018-11-19#1873650 << well, if i do common part (api) first, then diverging system-specific branches, i still could add new functionality on top of *each* of these branches. i don't like this option. -> perhaps unsurprisingly, the part that one doesn't like is however actually correct i.e. yes, you'll have to maintain the two separately if they are separate; hence my original "they are 2 trees" - because that's

bvt: but i see how this is the correct process, and just a bit more optimized case of what i planned with branches diverging at the genesis (saves reader some labour of reading same vpatches in each branch). and if tree becomes to messy, can regrind.

a111: Logged on 2018-11-19 23:03 asciilifeform: bvt: if you understand why bitcoin does not tolerate 'yes i'm on the same chain as you! except that i flipped a single bit in block 100, and really, honestly, nuffin ever depended on the tx where i flipped it!' -- you will also understand why v does not tolerate this either

asciilifeform: and yes it is true that if you write 6 platform variants today, and want to change the common trunk tomorrow, you will need to regrind all 6. but this is 'not a bug, but a feature'

asciilifeform: it forced you to proclaim that the 6 are in fact new programs, because you turned a common knob and potentially changed their meanings, of all 6

asciilifeform: this is the reason why asciilifeform is saving the optional asm subroutines in ffa for ~dead last~ ( per http://www.loper-os.org/?p=2735 proclamation ) rather than given in beginning of series

asciilifeform: if i had offered them in beginning, the architecture-specific pressable leaves will be gargantuan in size

asciilifeform: and reader would be stuck manually diffing'em, which defeats most of the win from using v vs signed tars etc

asciilifeform: given as i'd have to release N almost-completely-identical patches each time i release a chapter

bvt: i do understand the philosophy behind v (definitely not complaining), but i lack practical experience working with it, so it was useful to get explanations re tree structure.

asciilifeform: bvt: you will find, i think, that with experience comes 'ooooh, that's why, it was Right Thing all along'

asciilifeform: trinque: i admit that i sometimes miss the days when the amt of shit i gave re what the heathen exch rate is, was the size of a hamster's . pizarro is the 1 bone in throat on that score, it runs on heathenbux and consequently sensitive to the weather, like a bad knee

asciilifeform: prolly the only biz that dun have this problem at all, is s.mg, which of oct '18 broadcast reports '8`484.51538878', i.e. capitalized until the sun burns out ☟︎

asciilifeform: maybe in the end entire planet will end up as vertically-integrated suppliers for s.mg... ☟︎