75 entries in 0.693s
: if you actually, inconceivably but actually, start pruning
, can just as well do it as "will keep last n searches that weren
of middle' happens, in re konsoomer tech, but consider also that moar goes into garage, or even iraqi roadside mind,
: so I have been looking at v. (specifically asciilifeform's python version) it seems to me that there should be a "pruning
" step after the flow is laid out to remove any patches that are not ancestors of the desired leaf, so that you would not have to manually remove patches.
: well now i have to look into this and figure out what drives the memory of getting stuck. very foggy memories suggest it was the pruning
of spent outputs i was unsure of.
: mircea_popescu: we had this thread. if 'pruning
' is a thing -- monetary mass is no longer demonstrably capped.
: Seems you did pruning
of your own!
: a pressed-blockchain aluminum disk set would help to cool the enthusiasm of idiots pushing for 'pruning
', 'tx replacement', whichever lunacies crafted for 'let's make'em forget history'
: tx replacement , and the mere contemplation of 'pruning
', are a carefully crafted enemy rot weapon.
: i think pruning
would compare better to cutting everyone's throat "just a little" bit than "cutting one's own throat"
: so yeah, i'm satisfied with the answers in the sense that i did not miss any particular argument against pruning
: mircea_popescu: not really because i'm not particularly interested in discussing pruning
from a position where i'm somehow supposed to defend it
: which is basically what everything that has been said regarding pruning
boiled down to
: proponents of 'pruning
' want to replace 'the weight of 400k blocks' with a promisetronic 'checkpoint list'. which, i imagine the game plan is, to eventually include deviations from the usual proof of work, per gavin's unabashed declaration where 'WE say what the blocks were'
: blockchain replacement in a "pruned" scheme costs... whatever your pruning
: asciilifeform: yeah, sure you're not serving peers the historical data, that's the single thing that seems very wrong with pruning
, at least to me
: 'where did this money come from, how much exists in total' 'dunno, in the Great Pruning
of 2050 the scrolls of the ancients were lost'
: as a naive question, what exactly is the problem with pruning
: 'The list of all used transactions isn't readily available, and once pruning
shows up, it might not even exist at all. So, it only makes sense to compare the new coinbase to the list of transaction hashes that are unspent at the time ... ' << holy fuck the 1) idiocy 2) nobody challenged it, afaik
: 'Fully-spent transactions are allowed to be duplicated in order not to hinder pruning
at some point in the future. Not allowing any transaction to be duplicated would require evidence to be kept for each transaction ever made.'
: is it possible to do a lossless pruning
on this lubby thing? say some chunk of data kept in an early blk.dat can be removed and the whole thing still verifies because the missing piece can be re-produced from data in more recent blk.dat ?
: there's a reason i said 2 in 2 out. anything else is either nonmoving (1-2) or else tree pruning
(2:1 ends up with a single coinbase ; 1:2 ends up with an infinity of satoshi sized coinbases you might as well stop lying about and issue outright)
: i'm pruning
trustleaves slowly, but yeah need another degree of rigour hm
: because, for any given genesis block, the possible patches are universally available ; and the only way to obtain variant builds is through pruning
: to your point about "why is there no pruning
tool for this thing"
: I have spent countless hours pruning
a kernel config
: what new derp? SPV/pruning
/sig-check-skipping nodes exist already
: Next, future Bitcoin "optimizations": Removal of transaction data from blocks - Blockchain pruning
UTXO set commitments - Invertible Bloom Lookup Tables (IBLTs) - Moore’s Law - Kryder’s Law - Nielsen’s Law - Yet-to-be-discovered improvements"
: oh the functionallity of "automatically pruning
empty files" ?
the tree of all ulteriors that depend on an unclicked patch
: "Block pruning
works during initial sync in the same way as during steady state, by deleting block files “as you go” whenever disk space is allocated. Thus, if the user specifies 550MB, once that level is reached the program will begin deleting the oldest block and undo files, while continuing to download the blockchain."
: "The minimum was chosen so that Bitcoin Core will be able to maintain at least 288 blocks on disk (two days worth of blocks at 10 minutes per block). In rare instances it is possible that the amount of space used will exceed the pruning
target in order to keep the required last 288 blocks on disk." << RARE !
: highlight : "Block pruning
allows Bitcoin Core to delete the raw block and undo data once it’s been validated and used to build the databases. "
the resulting include-fixed directory. Thus, the only people who have to deal with fixincludes are people who build GCC from the source packages, or who are setting up build scripts for their own deployment/distribution.'
' offers a guarantee that the node won't be able to offer you a block which contains all spent outputs.
: BingoBoingo: Pruning
nodes can still validate transactions with recent inputs can they not? Or do they store all inputs. Need to read how it works
: I really fail to see much difference between the pruning
nodes and the pseudo-nodes
: /orionwl just merged pruning
support in /hashtag/Bitcoin?src=hash Core! Run a (no wallet) full node with 1.3 GB storage. Thanks to all who contributed.
: oh and btw reducing pruning
limit did not help here, fluffypony
: mircea_popescu: what pruning
: davout well the split happened after some pretty heavy duty pruning
: anyways asciilifeform how does the backported orphan-pruning
situation handle the full tree?
: Error! The resulting file count after pruning
did not match\n
: jurov looks at pruning
code in utter disbelief... was thinking that everyone konws the cp --parents trick to copy files named in manifest << i /knew/ there had to be an easier way. i seem to remember asking, but anyway.
looks at pruning
code in utter disbelief... was thinking that everyone konws the cp --parents trick to copy files named in manifest
has started to think of pruning
in a different manner - rather than reclaiming hard disk space, 'pruning
' just means you can provably flush certain transactions from various caches. it's a time/space optimization, not a change of the glob's outward behavior
: if transaction bloodline is bs, why are we against bc shelling/pruning
: gavinandresen: and disagree with the entire concept of 'pruning
: asciilifeform: again, go read the technical road map post, section on pruning
<< the shitgnomes don't dare a hardfork. so they'll happily try a 'lossy softfork' - see how much functionality can be degraded (in this case, how much of the blockchain can be alzheimered) without hardforking.
: mircea_popescu: i haven't been using the west key system to search. instead, i've been filtering for proceedings involving USG and then pruning
for terms like wiretap, warrant, email, hard drive, paperwork, and suppression of evidence.
: Implement UTXO commitments blockchain pruning
and fully validating but not full-history nodes << Killing this is basically the goal of Fall 2014-2015
: Implement “UTXO commitments” blockchain pruning
and “fully validating but not full-history” nodes
: well, it's definitely the blockchain-friendliest approach, seeing as only a hash is stored in the first place. moreover, i don't see how nonspendable tx helps anything other than pruning
: it's a middle pruning
control strategy, the exact equiv of raising taxes "for social good"
: and because of the pruning
it was a complete pain
: carefully pruning
the outdated utxos must be written from scratch :(