log
▁▁▁▁▁▁▁▁⏐▁▁▁ 3963
mod6: !!sent-invoices
mod6: !!ledger
deedbot: http://p.bvulpes.com/pastes/kNudj/?raw=true
deedbot: http://p.bvulpes.com/pastes/X6qez/?raw=true
asciilifeform: mircea_popescu: i expect the spammer folx will register their bots in short order. it takes ~0 work.
asciilifeform: whole thing is ~= a reddit.
asciilifeform: diana_coman: pretty great collection of http://btcbase.org/log/2016-01-21#1379603 . ☝︎
a111: Logged on 2016-01-21 13:29 asciilifeform: 'if i make it what i think is the right size, it crashes!111'
mircea_popescu: aha.
mircea_popescu: provided, of course, the whole show's not run off a script the kiddies bought from some dood in russia.
deedbot: http://qntra.net/2018/08/venezuelas-maduro-survives-drone-attack/ << Qntra - Venezuela's Maduro Survives Drone Attack
mod6: ben_vulpes: ok only had time today to start on reviewing the provisional july pizarro statement - going through your steps at the same time. so far, I can confirm the BTC incoming/outgoing is accurate.
mod6: will finish up the rest tomorrow (hopefully).
lobbes: http://btcbase.org/log/2018-07-22#1837189 << in other news, I finally figured out my issue. I failed to notice a very crucial piece of the 'logbot-check-mode' method (http://btcbase.org/patches/logbot-genesis#selection-1265.19-1265.63). i.e. the bot's nick has to have irc mode set to +o or +v or else 'logbot-start-pg-thread' and 'logbot-send-outbox' will not be invoked. ☝︎
a111: Logged on 2018-07-22 18:27 ben_vulpes: lobbes: that the outbox table has entries in it suggests that logbot-start-pg-thread was never called
lobbes: Bah, it took me way too long to figure that out. Anyways, thanks to all who helped me troubleshoot (phf, ty for pointing me to the hyperspec; I found that documentation to be especially useful on educating myself on the kidergarten-level things)
lobbes: I'll be sure to include this tip in the eventual guide hinted at in >> http://blog.lobbesblog.com/2018/07/logbot-multiple-channels-corrected-on-gentoo-tips-n-tricks-for-the-uninitiated/#selection-551.26-551.132
diana_coman: http://btcbase.org/log/2018-08-05#1839509 -> aha; legacy code is pretty much layers on top of layers of precisely that ☝︎
a111: Logged on 2018-08-05 00:18 asciilifeform: diana_coman: pretty great collection of http://btcbase.org/log/2016-01-21#1379603 .
asciilifeform: diana_coman: i think my comment went to your spam trap
phf: lobbes: hyperspec is first and last documentation you'll need for common lisp. it's generally a good idea to get a feel of what's where in it. it's the only authority on the expected behavior of your code.
phf: (in slime C-c C-d h on a standard common lisp symbol will open relevant hyperspec page for you)
diana_coman: asciilifeform, freed and answered; one of those days I will get around to relocating the blog too and restore its sanity re comments
asciilifeform: ty
asciilifeform: diana_coman: re 'student bloopers', 1990s classic re subj, https://archive.is/UyuCi ( rumoured to be a gag, but entertaining )
diana_coman: ah, ah, so at least there are jewels of bloopers
mircea_popescu: http://btcbase.org/log/2018-08-05#1839518 << it's always slow at first, dun sweat it. ☝︎
a111: Logged on 2018-08-05 05:13 lobbes: Bah, it took me way too long to figure that out. Anyways, thanks to all who helped me troubleshoot (phf, ty for pointing me to the hyperspec; I found that documentation to be especially useful on educating myself on the kidergarten-level things)
mircea_popescu: BingoBoingo "by explosive drones as his was giving"
BingoBoingo: ty fxd
mircea_popescu: diana_coman all muh comments go to modqueue!
mircea_popescu: in other items that probably actually belong here,
mircea_popescu: <milky25> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/
mircea_popescu: <milky25> "All told, Handshake aims to give $250 worth of its tokens to *each* user of the websites the company has partnerships with – GitHub, the P2P Foundation and *FREENODE*, a chat channel for peer-to-peer projects. As such, developers who have existing accounts on each could receive up to $750 worth of Handshake tokens."
mircea_popescu: <milky25> Handshake cryptocurrency scam is operated by Andrew Lee (276-88-0536), the fraudster in chief at Private Internet Access which now owns Freenode
mircea_popescu: <milky25> Freenode is registered as a "private company limited by guarantee without share capital" performing "activities of other membership organisations not elsewhere classified", with Christel and Andrew Lee (PIA's founder) as officers, and Andrew Lee having the majority of voting rights
mircea_popescu: <milky25> Even christel, the freenode head of staff is actively peddling this scam https://twitter.com/christel/status/1025089889090654208
mircea_popescu: <milky25> Don't support freenode and their ICO scam, switch to a network that hasn't been co-opted by corporate interests. OFTC or efnet might be a good choice. Perhaps even https://matrix.org/
mircea_popescu: "corporate" dun even begin to describe it. after i fucked that moron's ugly ass-face in every conceivable venue, he's actually "bought" freenode to try and impress ?
mircea_popescu: i'm not fucking impressed ; what the fuck, is it http://trilema.com/2017/in-scams-today-disk-less-terminal-sa-dba-laesquinadelamazmorra/#footnote_3_72501 hour now ?!
asciilifeform: lol cheapo nsa front co
mircea_popescu: you know ?
asciilifeform: what else is a 'vpn'
asciilifeform never was able to fathom what 'vpn' subscribers have in their crankcases instead of brains, to fall for such a thing
asciilifeform: the 'dun fall for fleanode, switch to OUR nsa honeypot instead' spamola is lulzy.
mircea_popescu is particularly unimpressed by the sort of fucktard who goes all http://trilema.com/and-in-todays-lulz-the-obnoxious-cocksucker & http://trilema.com/2014/the-public-burning-of-bob-beck/ on me when i come offering ~a little~ actual money ; and then rolls over for usg's own "offers" of EXACTLY ZERO.
mircea_popescu: fucktards.
asciilifeform: mircea_popescu: i suspect they dun want and can't use money for anyffing. they want miami.
mircea_popescu: which is precisely the problem, because "they want miami." is just a polite way of saying "however many bn cuntsquirts walk about, there's never bneen more than a million or two souls, and these schmucks don't got one."
asciilifeform: same as openbsd.
mircea_popescu: hence the link.
asciilifeform: the cocksucker is hungry for specifically obummer's cockjuice, nothing else will satisfy.
mircea_popescu: and now back to actual topics, moron interest fades quickly.
asciilifeform: in other noose, buffer overflow found in... zcat.
asciilifeform: ( for bonus lulz, was triggered by an intel official microcode patch as gzip payload... )
mircea_popescu: bwahah
mircea_popescu: can't even keep all the nobusi straight anymoar.
asciilifeform: overflowlang ftw.
mircea_popescu: poor mod6 btw. he sounds like he's got himself well up to the ears.
diana_coman: mircea_popescu, yes, ALL comments go to modqueue atm
mod6: Hai
mod6: So the USD Incoming/Outgoing table in the July provisional pizarro statement looks correct to me. The only thing I would adjust is the statement about Fiat expenses. Whereas, I agree that all the work could be done from the apartment and we no longer need the co-work space. I'm inclined to let BingoBoingo make the decision there, and it sounds like he wants to take it down to "part-time", which should red
mod6: uce the cost.
mod6: Further more, he seems to like it as a good place to receive items. So maybe just strike the part that says "no further need for coworking desk" and edit to something like "expected reduction in cost for cowork desk" or something thereabouts.
mod6: The Fiat Assets table looks correct to me from following the steps, and when including the outgoing $186 adjustment value in the USD Incoming/Outgoing table.
mod6: The Fiat Liabilities table looks right -- My understanding here is that we have a $2500 entry here for the wildcat bonus because we initially allocated the wildcat bonus for $7500, paid out $5000, and are carrying the libility forward until it's paid September 1st. Correct ben_vulpes ?
mod6: Yikes, here we go through the tangibles table. :D
mod6: !Qcalc 1313/6800
lobbesbot: mod6: 0.193088235294
mod6: !Qcalc (44900*0.033)/6800
lobbesbot: mod6: 0.217897058824
mod6: ben_vulpes: qq on the UYU book value -- you listed 0.21648971 , but I get the above ^ am I doing that correctly? Or am I using a bad UYU/USD number?
mod6: !Qcalc (44900*0.032)/6800
lobbesbot: mod6: 0.211294117647
mod6: hmm. yeah, let me know on this one.
mircea_popescu: diana_coman aok
mircea_popescu is off to the beach, ttys!
mod6: My only other question on the Tangibles table is that UY3 was not depreciated, even though it was in service for 19 days. Should there be some sort of prorated depreciation on this?
mod6: c-ya mircea_popescu
mod6: have fun
mod6: !Qcalc 0.55312191-(((0.55312191/12)/31)*19)
lobbesbot: mod6: 0.524871059758
mod6: !Qcalc (((0.55312191/12)/31)*19)
lobbesbot: mod6: 0.0282508502419
mod6: This make sense for book value after prorated depreciation (fist number). Second number is the prorated depreciation.
mod6: !Qcalc 0.55312191/12
lobbesbot: mod6: 0.0460934925
mod6: ^ Full month depreciation would be this.
mod6: Correct?
mod6: Ok moving on to the Pizarro Assets table
mod6: Before I do that, I forgot to sum the values in the book value column in the Tangibles table
mod6: !Qcalc 0.14906164+0.30000001+0.08109780+0.55312191+0.38888892+0.19308823+0.21648971+0.25106448
lobbesbot: mod6: 2.1328127
mod6: Ok we're not getting the same sum of the tangible book values, did I add something in that I wasn't supposed to?
mod6: Ok now actually moving on to Pizarro Assets table.
mod6: Ok, first question on this part is how we got to the 7/31/2018 (end of july) cash amount of: 6.48908190
mod6: Here's what I come up with on my own, would be the Sum of the BTC on hand (in mod6's deebot account, minus the 0.08479669 that was in there previously to pizarro's BTC deposit), plus the BTC book value of the USD, and the BTC book value of the UYU:
ben_vulpes: mod6: the UYU book value will indeed fluctuate based on what number you use for the usd/uyu exchange rate
mod6: !Qcalc ((((6.14882560-0.08479669)+0.19308823)+0.21648971)
lobbesbot: mod6: Error: unexpected EOF while parsing (<string>, line 1)
mod6: !Qcalc (6.14882560-0.08479669)+0.19308823+0.21648971
lobbesbot: mod6: 6.47360685
mod6: So we're close here, but not quite to the 6.48908190 that is in the table
ben_vulpes: check to see if it's the difference between our btc values of uyu
mod6: ben_vulpes: gotcha. any idea what number you used? This should go into my notes so I know to record the UYU/USD exchange rate at the time of the setting of the monthly price point.
mod6: im using your UYU value actually. (i'm only pointing out the differences, not using them in the calcs)
ben_vulpes: 30.500
ben_vulpes: mod6: you may want to check your account history, BingoBoingo is also sitting on 0.2 of pizarro's btc
mod6: !Qcalc (6.14882560-0.08479669)+0.19308823+0.21648971+.2
lobbesbot: mod6: 6.67360685
mod6: So the nubmber im using '6.14882560' is from my ledger after Mr. Popescu paid the S.MG UY3
mod6: the 0.22505299 wasn't included there, lemme try again
mod6: !Qcalc (6.14882560-0.08479669)+0.22505299+0.19308823+0.21648971
lobbesbot: mod6: 6.69865984
mod6: (im adding that in, because even though it was paid on 8/3 it belongs in the July statement - as you have also listed it in the BTC Incoming/Outgoing table.
mod6: )
mod6: For my notes, could we say, in general, that to get to this month-end cash asset number, you take the BTC amount on-hand + USD value in BTC + UYU value in BTC?
mod6: Anyway, take your time, I'm gonna keep going here.
ben_vulpes: more accurately it's cash + tangibles, and various fiats are tangible assets.
mod6: all tangibles?
ben_vulpes: no hang on, no. btc is the only cash.
mod6: or just the fiat or other cash lines?
mod6: ok
ben_vulpes: usd/uyu are fiat assets. get booked as tangibles. see the tangibles table.
mod6: so -just- btc
ben_vulpes: correct.
mod6: !Qcalc (6.14882560-0.08479669)+0.22505299+0.2
lobbesbot: mod6: 6.4890819
ben_vulpes: per http://trilema.com/2013/accounting-for-the-nonzero-asset-corporation-the-mpex-standard/#selection-129.0-129.120
mod6: perfect, that's exactly the number I was looking for.
ben_vulpes: what is that .08 you're subtracting out?
ben_vulpes: oh, this is summing accounts and pulling your change out of your deedbot balance?
mod6: it's the amount that mod6 himself had in his deedbot account before I was sent Pizarro's 6.21445021 BTC.
ben_vulpes: ding ding ding, okay.
mod6: must be subtracted out from here on out.
mod6: well, at lesat, until I send them to BingoBoingo, in which case, he might have his own subtraction he'll have to do. that's the messiest part of doing the pizarro thing through personal deedbot accounts.
mod6: it would be nice if pizarro had it's own key and could keep it's own ledger, but then who would control or hold said key, and that doesn't work either.
ben_vulpes: book truth lies in the statements; it is useful to verify that the cash line is correct but i would use it as a check, not the starting point from which to generate statements given a) payment timing b) personal use of accounts
ben_vulpes: mod6: nothing stops you from doing this
mod6: i've thought about it. maybe further discussion around the topic will help change my mind.
ben_vulpes: anyways yes, if you want to audit the correctness of the statement against the value of cash held on behalf of pizarro, you will have to deduct your personal transactions from whatever account pizarro transactions flow in order to calculate a correct number.
mod6: i honestly think that would be a much clearer accounting way to go.
mod6: right.
ben_vulpes: mod6: for what it's worth, i twice audited holdings while generating statements and they both came out correct. i suggest you use the statement generation process (combing through ledger/invoice output) to generate statements first, and audit against your personal accounts as a check.
mod6: ok so now that i've figured out that cash number from the Assets table, there will still two other questions for you above ^ when you get a chance: the depreciation of UY3, and the sum of the book values.
ben_vulpes: can prorate depreciation if you'd like, i elected not to.
mod6: ah, i see. ok.
ben_vulpes: let me sum assets again.
mod6: i was just following your steps, and since it was actually in use, figured that maybe we just forgot about it.
mod6: and btw, the steps are very helpful! thank you much for writing themup
ben_vulpes: mod6: i did not update that row after using the wrong conversion factor for fiat liabilities on my first pass; thank you for spotting that
ben_vulpes: scuse me, fiat tangibles.
ben_vulpes: http://btcbase.org/log/2018-08-05#1839607 there is a fine point here, that this is notionally a "closing-of-the-month" value for the UYU ☝︎
a111: Logged on 2018-08-05 20:51 mod6: ben_vulpes: gotcha. any idea what number you used? This should go into my notes so I know to record the UYU/USD exchange rate at the time of the setting of the monthly price point.
ben_vulpes: we're talking tiny amounts of btc, but good process and understanding are important at the outset to forestall tears later, so bear with me
mod6: ok np at all, just trying to get the process of getting these numbers. take your time. i feel like I'm learning a lot here with all of this, it's super helpful.
ben_vulpes: the past two statements i have pulled that value from xe or forex.com at the time of statement generation. if you want to couple the UYU/USD price timing to that of the USD/BTC price timing, you'd have to hold off on issuing the previous month's statement until you have a btc price signal /for the month after the statement/, and then ask BingoBoingo what the uyu/usd rate is on that day in order to provide a
ben_vulpes: value for the previous month's closing value of the uyu/btc rate (which is also the opening rate for the next month)
ben_vulpes: i do not think that this coupling is necessary, however. a photo of the exchange rate from BingoBoingo at the same cambio on the 27th every month may be adequate.
mod6: ahh, alright. i get what you mean. so it's a bit simpler to just get the forex number at the time of the statement, rather than having to old up the previous months statement until a BTC/USD price point is established.
mod6: I think I'm alright with that, again, if it's considered a "notional" number.
ben_vulpes: yeah, keep in mind that the tangibles line is, again per "Accounting for the nonzero asset corporation" "any and all assets that could reasonably be expected to be exchangeable for BTC, even if at a loss"
ben_vulpes: so accounting's job is to provide a reasonable, non-malicious estimate of that value, and let investors perform their own valuation based on whether they think that a high or low value for the tangible in question.
mod6: I'm on step 10.4 here... having some trouble.
mod6: gonna read through the steps again
BingoBoingo: <ben_vulpes> i do not think that this coupling is necessary, however. a photo of the exchange rate from BingoBoingo at the same cambio on the 27th every month may be adequate. << This I can do
ben_vulpes: mod6: 10.4 is more of a note about what happens in various scenarios than instructions relevant to anything happening in this month's report
ben_vulpes: derp 10.4, not 9.4
mod6: yeah, looking at 10.4
ben_vulpes: mod6: what is unclear about that line?
mod6: just a sec
ben_vulpes: a possibly relevant thread: http://btcbase.org/log/2016-08-06#1515831 ☝︎
a111: Logged on 2016-08-06 04:47 ben_vulpes: mircea_popescu: how does the server rental fee make sense as "intangibles and goodwill"?
mod6: ok, so where do we get the month-end number for intangibles, g/w "5.59699926" ?
ben_vulpes: sum of previous month's goodwill and this month's goodwill
mod6: oooh ok. lemme check that.
ben_vulpes: calculated per "sum the value of all non-capitalized purchases (DC, fiat spent denominated in BTC, and the sum of depreciation charges), and mark that as net change for intangibles and goodwill"
ben_vulpes: (the 10.4 under discussion)
mod6: Yeah, didn't realize that I had to add in the number from the beginning of the month (end of last month), in this case "4.77078675"
ben_vulpes: ayup, this is how the bottom-of-the-report tables work: summing the previous months values against the current months values to derive a current number.
mod6: so, i'm close now, but not quite, here's what I'm getting:
ben_vulpes: (to be used in next months reports, etc. hence "reports as ground truth and not your account balance")
mod6: !Qcalc 4.77078675+0.46713262+0.3+(0.02129452+0.03333333+0.00901087)
lobbesbot: mod6: 5.60155809
ben_vulpes: how about we just look at the net change, first
ben_vulpes: first off, the .3 btc was spent on cash
ben_vulpes: i mean to say that the .3 btc was spent on usd, some fraction of which was not in turn spent on expenses.
mod6: Which is: The number from the beginning of the month <first number> + DC payment <second number> + living expenses <third number> + sum of depreciation from the tangibles table
ben_vulpes: right, so factor out the invariant and let's calculate the net change since that's where we'll find discrepancies.
ben_vulpes: !Qcalc 0.46713262+0.3+(0.02129452+0.03333333+0.00901087)
lobbesbot: ben_vulpes: 0.83077134
ben_vulpes: some .04 btc discrepancy from the report
ben_vulpes: .004!
mod6: yeah, i noticed this before that it's not quite the same number as listed in netchange
ben_vulpes: a bitcent says that's the difference between purchased usd and expenses denominated in usd, redenominated in btc.
ben_vulpes: !!up candi_lustt
deedbot: candi_lustt voiced for 30 minutes.
mod6: !Qcalc 0.83077134-0.82621252
lobbesbot: mod6: 0.00455882
ben_vulpes: candi_lustt: (+ 0.46713262 (/ (+ 186 311 620 183 459 58 44 69 35 44) 6800) (+ 0.02129452 0.03333333 0.00901087))
ben_vulpes: !W (+ 0.46713262 (/ (+ 186 311 620 183 459 58 44 69 35 44) 6800) (+ 0.02129452 0.03333333 0.00901087))
candi_lustt: ben_vulpes: 0.8262125
ben_vulpes: the slut is truncating
mod6: lol
mod6: the good ones don't!
ben_vulpes: show me the perl that doesn't mangle double floats...
ben_vulpes casting baseless aspersions
mod6: q% perl -e '$a=0; $a=0.46713262+((186+311+620+183+459+58+44+69+35+44)/6800)+(0.02129452+0.03333333+0.00901087); print "$a\n";'
mod6: 0.826212516470588
mod6: rounded down though >D
ben_vulpes: like i said, baseless aspersions
ben_vulpes: and it's a truncation, not a rounding
mod6: actually, no that's right. not rounded at all.
mod6: hahah, fun
mod6: ok. moving on.
mod6: gonna check out this liabilities table
ben_vulpes: mod6: what else troubles ye, i have other sisyphean boulders slipping back downhill as we speak
mod6: go do what ya gotta do. i said I was gonna go through this whole thing, and learn some stuff.
mod6: anything else can wait.
mod6: thanks for stopping in to help fill in the gaps, I appreciate that.
ben_vulpes: i'm here, we're close to the bottom. may as well finish it out.
mod6: cool, one sec, will start in on it.
mod6: dear lord, this customer equity line
mod6: oh boy
ben_vulpes: yeah have fun
ben_vulpes: i'll be back later
mod6: ok
mod6: !Qcalc 2500/6800
lobbesbot: mod6: 0.367647058824
mod6: the wildcat bonus is listed as '0.30487805'. Am I doing something wrong, or missing something above ^
ben_vulpes: no, that's correct
ben_vulpes: yours, i mean.
mod6: alrighty
mod6: ok, so I've gone through this table, aside from the customer equity line, and it looks good.
mod6: I've gotta run for a bit here, maybe later when you're availble we can go through calculating that customer equity. i did some adding, but I came up about 50% short. clearly missing something there.
mod6: but let's leave this for another day.
jurov: mod6: won't it be sufficient to do depreciation once per year, if at all?
jurov: second question is, are you clear how exactly are you doing it. tracking and depreciating every item is imo unnecessarily hairy
jurov: *every item separately
jurov: So far I'm not doing depreciation at all. Only have to take care when an item is broken/sold, that the correct amount is subtracted from tangibles.
asciilifeform: !!later tell phf http://btcbase.org/patches/zfp_2_noc << is not a valid vpatch !!!!!! and yer viewer should have rang the alarms. it references files not in the genesis !
asciilifeform: grrr
asciilifeform: !Q later tell phf http://btcbase.org/patches/zfp_2_noc << is not a valid vpatch !!!!!! and yer viewer should have rang the alarms. it references files not in the genesis !
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: !Q later tell ave1 http://ave1.org/code/zfp/v/patches/zfp_2_noc.vpatch is an invalid vpatch, it breaks fundamental rule of vtronics , by referencing files not given in the genesis !
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: it is impossible to press this tree except by abusing a vtron!
asciilifeform: this is asciilifeform's 'shiva' blunder all over again.
asciilifeform: ave1: pleeez make a real genesis ? so i can test this ? thx
asciilifeform: http://p.bvulpes.com/pastes/ap30o/?raw=true << ftr, what happens if you do try to press it. it balks, given as a/examples/constraint/constraint.adb 2df5271a0e78caef0b8281740aeaae60e9e298614951710fd488b7cefc268d151729a682bce66205d310c45a8afb6fa173b1c4e9331fc5ec3cdabdf6663c86eb never existed in genesis.
asciilifeform: or hm, am i simply missing a patch ??
asciilifeform: looks like i am. 'zfp_1_examples' apparently. so this ~is~ shiva all over again.
asciilifeform: my vtron still won't press this, btw, even given all 3 patches.
asciilifeform: ( i'ma have to find out why. )
asciilifeform: mod6's, ftr, won't either, and it sees only the genesis in the flow.
mod6: seems to work ok for me: http://p.bvulpes.com/pastes/qIW0e/?raw=true
mod6: jurov: um, not sure? i would venture to guess that we depreciate monthly as it's possible that a piece of equipment might die before a year is up, or even come DOA.
mod6: ben_vulpes: thoughts on jurov's questions?