no, memory is not just used for 1MB blocks. it's also used to store the mempools plus the UTXO set. large block attacks
Again, you're wrong on the technology. The UTXO set is not held in ram. (There is caching, but its arbritary in size, controlled by the dbcache argument).
have the potential to collapse a full node by overloading the memory. at least, that's what they've been arguing.
"They" in that case is sketchy nutballs advocating these "stress tests", and _you_ arguing that unconfirmed transactions are the real danger.
Super weird that you're arguing that the Bitcoin network is overloaded with average of space usage in blocks, while you're calling your system "under utilized" when you're using a similar proportion of your disk and enough of your ram to push you deeply into swap.
There is no requirement that mempools be in sync, -- in fact, they're not and the whole purpose of the blockchain is to synchronize nodes. The mempools of nodes with identical fee and filtering policies and whom are similarly positioned on the network will be similar, but any change in their policies will make them quite different.
well, that was precisely Peter's mathematical point the other day that you summarily dismissed. f2pool and Antminer are NOT in a similar position on the network as they are behind the GFC. they have in fact changed their verification policies in response to what they deem are large, full blocks as a defensive measure. that's why their average validation times are 16-37sec long and NOT the 80ms you claim. thus, their k validation times of large blocks will go up and so will their number of 0 tx SPV defensive blocks. and that's why they've stated that they will continue to mine SPV blocks. thanks for making his point.
PeterR wasn't saying anything about mempools, and-- in fact-- he responded expressing doubt about your claim that mempool size had anything to do with this. Moreover, I gave instructions that allow _anyone_ to measure verification times for themselves. Your argument was that miners would be burned by unconfirmed transactions, I responded that this isn't true-- in part because they can keep whatever mempool size they want.
To further make the point about mempools, here is what the mempool looks like on a node with mintxfee=0.0005 minrelaytxfee=0.0005 set:
$ ~/bitcoin/src/bitcoin-cli getmempoolinfo
{
"size" : 301,
"bytes" : 271464
}
it also is a clear sign that miners do have the ability and financial self interest to restrict block sizes and prevent bloat in the absence of a block limit.
Their response was not to use smaller blocks, their response was to stop validating entirely. (And, as I pointed out-- other miners are apparently mining without validating and
still including transactions).
these SPV related forks have only occurred, for the first time ever, now during this time period where spammers are filling up blocks and jacking up the mempool. full blocks have been recognizable as 950+ and 720+kB. this is undeniable.
If we're going to accept that every correlation means causation; what should we say about the correlation between finding out that you've taken hundreds of thousands of dollars in payments for paid shilling and finding out loud and opinionated you are on this blocksize subject?
In this case, these forks are only visible by someone mining an invalid block, which no one had previously done for over a year.
if they are seeing inc orphans, why haven't they retracted their support of Gavin's proposal
They are no longer seeing any orphans at all, they "solved" them by skipping validation entirely. They opposed that initial proposal, in fact, and suggested they could at most handle 8MB, which brought about a new proposal which used 8MB instead of 20MB though only for a limited time. Even there the 8MB was predicated on their ability to do verification free mining, which they may be rethinking now.
i don't believe that.
I am glad to explain things to people who don't understand, but you've been so dogmatically grinding your view that it's clear that every piece of data you see will only "confirm" things for you; in light of that I don't really have unbounded time to waste trying. Perhaps someone else will.
