asciilifeform: 'pruned blockchain' is a fundamentally fraudulent object.
asciilifeform: likewise for the reason that ~someone~ still has to keep the world history around. as soon as it is not practically accessible to ~anyone, it becomes possible to 'consensus' and fiatolate.
asciilifeform: mircea_popescu: orlov phrased same lemma with different pieces -- '90s ru produced a dictum, 'don't lend more than it'd cost the creditor to take a contract on you'
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: danielpbarron: expiring addrs are problematic in their own way, see the 'canned tx' discussion from few days ago
asciilifeform: 'you bring bigger scissors --- we bring bigger rock'
asciilifeform: aint' that what 'difficulty' is for ?
asciilifeform: danielpbarron: was the direction i was thinking in, earlier
asciilifeform: mempool spam is ~uninteresting in the long term, wotronic solution solves it
asciilifeform: this solves mempool spam but not the basic problem where a tx sitting in a block is an infinite, recurring cost, while the cost of creating it is finite and one-time.
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: (test of heat sink, perhaps. but 0 else.)
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: mircea_popescu: would have to have some equivalent of fs journal
asciilifeform: ^ can anyone find this piece ? or it evaporated.
asciilifeform: (speaking of proofofwork -- iirc szabo had a lulzy piece about two tribes of northwest-american indians who traded sea shells that were too abundant in each tribe's section of the coast to use as proofofwork, to the other, where they were usable )
asciilifeform: there are two known solutions to 'allcomers problem' -- proof-of-work; and limited-access (wotronic). tertium ~probably~ non datur.
asciilifeform: needless to say this would be riotously bad idea if pools remain possible (they must - protocolically - die.)
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☝︎
asciilifeform: to revisit upstack: mircea_popescu can you think of any reason not to queue the writes ?
asciilifeform: 'George W. Bush on Trump's Ties to Russia: 'We All Need Answers''
asciilifeform: in other lulz, we still see 'ProcessBlock (res == 1) took : 673809ms; db write wait: 397971ms; db read wait: 64890ms' (block 454992) and 'ProcessBlock (res == 1) took : 456196ms; db write wait: 179701ms; db read wait: 16621ms' (454993) . enemy's strategy is quite trivial, thrash the cache.
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: gprof is the divinely ordained proper way to do this. however will need a bad old dynamic linking build. so will take some work.
asciilifeform: it isn't clear to me, that it does. the typical verification time is ~same
asciilifeform: 64bit linuxen on x64 will happily allocate moar. it is bdb that is retarded.
asciilifeform: ( i would try a larger cache, but 4GB is the idiot hardcoded max in bdb , they used a 32bit width )
asciilifeform: will be interesting to see if this abolishes '30min blox'
asciilifeform: it is running on dulap, and will run there until further notice.
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.
asciilifeform: it appeared to have 0 effect, but after cache had a chance to fill -- now this.
asciilifeform: ^ very puzzling result, and now finally similar to mircea_popescu's 'disk and Other Factors'
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.
