log☇︎
71600+ entries in 0.529s
asciilifeform: i know of no serious candidates.
asciilifeform: danielpbarron: as i currently understand it, the encumbrance algo is the boojum.
danielpbarron: asciilifeform, i had a very similar idea re: staged-mining. came to it in considering a quality-coin where value is a product of quantity of units and a factor which decreases with each passing block
asciilifeform: (before anyone laughs, i will point out, yes, the necessary mechanical parts for this do not presently exist.)
asciilifeform: !~later tell mircea_popescu here's another crackpottery in re the nodes/miners/txers 'racul, broasca si o stiuca' : ~multistage mining~. where a node can encumber (protocolically/mathematically - for now i will not specify how) a tx with some proofofwork, when passing it on to next relay; and when the tx is mined, the block reward is split between the multiple parents of the final tx.
asciilifeform: damn, i was hopin' he'd tell us about something he'd... gone, and gotten
aseriousgogetta: do as much as i can with what little i have.
mircea_popescu: "i can scarcely see how could there be more of that"
a111: Logged on 2017-02-19 18:39 mircea_popescu: reported by the miner that included it, as best i can tell.
mircea_popescu: i can scarcely see how could there be more of that, but ok.
mircea_popescu: now, the objection can of course be raised that "what guarantees do i have someone will marry me", to which the answer is of course both none and fuck you. it works if you work it, as the expression goes.
asciilifeform: 'hey ftmeade, can i haz my phone call from last week'
mircea_popescu: as large as mining farms, or larger. or i guess less large - by an adjustable factor.
mircea_popescu: 1trn* i mean
mircea_popescu: but the correct trb-i might just as well end up this situation where block reward is 1mn bitcoin, and it dies within 1mn blocks. so all mining does is produce ~ a lease ~ on a chunk of bitcoin. and the value of old bitcoin is monotonically decreasing over their lifetime. ☟︎☟︎
asciilifeform: as i understand it, there cannot be such a thing as 'safely pruned'
asciilifeform: this is the mega-problem i was stabbing at, in the earlier nodes thread
mircea_popescu: this will necessarily mean that the woman does not own her body, in some sense and to some degree, when discussing cunts ; and that i don't know what the fuck unpleasantry, when discussing bitcoin.
asciilifeform: danielpbarron: i can't speak for others, but i'd have 0 interest in a bitcoin where you can cause someone's coin to evaporate by disrupting his net connectivity for a decade or two (e.g., by imprisoning)
asciilifeform: danielpbarron: one of the fundamental attractions, as i see it, of bitcoin, is that it is devoid of the idiot usg-powered musical chairs of 'keep moving the money or we'll steal'
asciilifeform: i suspect that this is a 'heat death' problem that cannot be fully dealt with.
asciilifeform: danielpbarron: was the direction i was thinking in, earlier
mircea_popescu: asciilifeform this is not directly obvious. anyone may publish any bullshit they want, and i spend 0 cycles not reading it.
asciilifeform: the finding i keep bashing my head against, is the realization that the current scheme ('anyone can make any number of valid tx they want, and everyone else must spend cpu cycles again and again and again testing it') has no future.
asciilifeform: that's what i suggested earlier
asciilifeform: ( i can picture that people wishing to 'be bank' will bid up the cost of txing, by pushing up difficulty. but the wotronic answer -- limit access to nodes to 'subscribers' -- also threatens to re-create banks, neh ? )
asciilifeform: mircea_popescu: just to make it absolutely clear, i don't see a long-term future for satoshi's turd. all of my work on trb is to be regarded in same light as the neutron-absorbing armour on 1970s sov tanks -- something with which to prolong the life of the crew ~slightly~ so that it can drive over freshly-nuked ground and last a few hours of shootout.
asciilifeform: (i.e. 'these writes don't count until X is also written')
asciilifeform: to revisit much further upstack, to http://btcbase.org/log/2015-02-14#1018732 ( via mircea_popescu's latest article ) -- consider a 'trb-i' where a tx carries proof of work, and is likewise mined as is the block ☝︎
mircea_popescu: which is the substantiation for the 70bn yet figure i quoted.
asciilifeform: as i expected
asciilifeform: http://btcbase.org/log/2017-02-27#1619009 << i'd much like to hear the details of this, if they exist somewhere. because the Official version makes 0 sense ☝︎
asciilifeform: (i really oughta say 'verify and save', rather than verify)
asciilifeform: however the one solid clue i have so far is 'disk' -- on the ssd box, a block packed to the bursting point with liquishit, takes ~15 seconds to verify. max.
asciilifeform: the unfortunate bit is that i do not have 2 identical boxes to run the cache/no-cache variant on, in parallel
mircea_popescu: phf i am not surprised, it's pretty jarring as far as these get.
mircea_popescu: i wasn't aware, but hey.
mircea_popescu: trinque if it helps, the last that i see on the path to you is 38.104.87.131 (joe's datacenter). 104.192.170.197 is also allocated to them. 138.107.206.73 however does not, it's "olympus corporation" of kiminobu eto, takuro watabe & toru yamaki whatever japanese company. why's that in there.
phf: i couldn't get past title. "ten tricks international oil conglomerates that run everything hate"
trinque: I have no idea, really, which is always the worst answer
trinque: same routing table upon reboot, so I guess it's normal for their network
ben_vulpes: i'll just keep mashing buttons not hooked up to anything, like an ape
trinque: I'm into the box; give me a while to actually figure out what happened
trinque: I'm obviously going to tell them *not* to reboot
trinque: I'm checking in with the host
trinque: PSA that as of now I cannot access the box hosting deedbot via SSH.
asciilifeform: possibly best thing i ever saw in a cinema.
asciilifeform: i'dvethunk they'dve been danced out by nao
shinohai: I adore that particular Trilema article
mircea_popescu: i think it's more in the vein of out and out pederasty.
asciilifeform: what else to do, the original lure of vacuuming up coin is , i picture, ~gone by now
mircea_popescu: it's been dead for about a year or so, but anyway, "oh i know, i'll make yet another fake wot website. because i'm a jew and we're fucking stupid congenitally." or some shit.
asciilifeform: ( i would try a larger cache, but 4GB is the idiot hardcoded max in bdb , they used a 32bit width )
asciilifeform: mircea_popescu: the 40-80 secs. verifications are still 15x slower than on zoolag (ssd box). i wonder, possibly , if the remaining delay still consists of disk -- but of block fetches, rather than tx index.
jurov: i don't get why that bothers you so much
jurov: looky, i am just saying that right now it eats, say, a minute per block, which is 144 minute unreachability daily anyway. and am proposing short term tradeoff of having the unreachability shorted once per day.
asciilifeform: i already once built a system where the reward for enemy for unplugging seeped into days, weeks, then months of lost cpu time. until the unplugging became an inevitable thing. never again.
asciilifeform: but i have zero interest in designing a bdb-like abortion. for any purpose.
asciilifeform: jurov: this is an open question. for all i know, bdb will reach some idiot hardcoded limit long before this.
asciilifeform: if i'm backing up across the net -- then yes, pretty close to that
asciilifeform: so now if i need 24/7 access to the network, i gotta keep... 24 nodes
asciilifeform: say i can finally buy jurov's magical disk, where backup AND restore of 30GB (that's just the tx index) takes only 1 hr.
jurov: i'm still waiting for explanation how did you came to double digit downtimes.
jurov: yes, it will sit as a brick and i'm fine with it.
jurov: i'll use another node. or you're supposed to have a precious one and only one?
asciilifeform: and i'm still waiting for an answer, what is the node to do during backup and during restore of same ?
jurov: i said i do sync, then backup
jurov: but this will happen if, and only if, power is cut. if i sync once per day and backup the x, the backup will keep the x forever
asciilifeform: whatever you want to call it. it is not and will not be an invited guest anywhere i am answerable for.
asciilifeform: understand, if my proggy writes an x to disk, at some point, and then later i read a y, and y != x, this IS CORRUPTION
asciilifeform: jurov: people flush write caches purely from hallucination ? maybe i don't need a disk at all then ?
asciilifeform: i suppose one way to rebuild the index using existing mainline trb would be to nuke the .bitcoin dir entirely, and refeed the node via 'eatblock'.
mircea_popescu: this is why i say expensive, it's not a case of "random vps hur durr".
mircea_popescu: no but i mean, a 30gb ramdisk node to support the general public's mistaken notions and unwarranted pretensions... meh.
mircea_popescu: i will note that this is an expensive and unrewarding activity that i personally discontinued cca 2014.
mircea_popescu: asciilifeform i don't really do blockchain.info style "public support". i think i have the stuff somewhere, i'll have to dig for it. basically it's, blk* live on /sda ; blkindex.dat and friends live on /sdb which happens to be a ramdisk.
asciilifeform: jurov: the most sane variant of your proposal i can think of would be to run the entire tx index in memory. this is just barely practical on dulap, a massive box. and would mean multi-hour regeneration of the index on warmup. but is at least theoretically an improvement, in that it does not threaten to randomly lose bits.
jurov: Suppose i shutdown bitcoind and backup .bitcoin using rsync (so that all files with recent mtime are backed up).. you say this won't work?
asciilifeform: copying 400GB takes 'few minutes' on jurov's disk ? where can i buy one ?
jurov: You run some service that needs five-nines availability? I'm fine with some of my nodes being down for few minutes to have known-good state backed up.
a111: Logged on 2017-02-19 03:54 asciilifeform: (iirc we had a thread where i described how corporate ameritards, if given a problem like phuctor, would happily soak up a few $mil and megawatt of iron)
asciilifeform: nonsense like 'let's flush write cache once in a blue moon instead of normally', 'let's let the db corrupt and SURE I PROMISE WE CAN RECOVER' is what winblowz world is built from.
asciilifeform: i'm not willingly building another phuctor-1.0, nothx.
asciilifeform: just what i need, in my node!11!!!! random corruption.
asciilifeform: why would i want to turn off the journal ?
asciilifeform: if mining were not an intrinsically heathen activity, 'closed network' would solve the 'allcomers' problem. but as i currently understand, it'd simply ~move~ it.
asciilifeform: i could cut off public ip access right now -- and never see a block again.
asciilifeform: my house is a poor example, i suspect that squirrels could tip it.
asciilifeform: the unfortunate bit that i keep coming back to in my head, is that http://btcbase.org/log/2017-02-26#1618702 + http://btcbase.org/log/2017-02-26#1618674 add up to a fundamental boojum, that is not a matter of simply 'make a faster db, buy a faster disk' ☝︎☝︎
mircea_popescu: 60ish or so deep if i recall.
asciilifeform: i have this notion, that there was a massive one some time before i tuned in.
a111: Logged on 2016-12-19 18:18 ben_vulpes: asciilifeform: if martians produce longest chain with greatest difficulty i think by the rules of the game they own bitcoin
mircea_popescu: there is that. i'm just saying, you can have nonrewritable media, whatevs.
mircea_popescu: i dunno. coupla people sorta-promised to sorta-try.
mircea_popescu: but i have nfi whether this is even feasible, because this'd be step 2, after the "hey, what happens if you fill a disk with symlinks" EXPERIMENT returns some fucking results.
mircea_popescu: no, it'll be a mildly configured ext4 i guess
asciilifeform: (a trb-i item )
asciilifeform: symlink gets you a file containing desired block, but there is no way on any unix fs that i know of, to symlink to ~an offset inside a file~
mircea_popescu: i thought that was the idea anyway
mircea_popescu: i thought modern raid controllers did