Topic: Gold collapsing. Bitcoin UP. - page 148. (Read 2032248 times)

Where I expicitly pointed out to you in many places, in excruciating detail, that this was not at all the case??  https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5?context=3   You seemed so happy to argue with it before, has your memory vanished now that you don't think it would be convient for you?


The incohearence in some of these posts is so foaming so thick that it's oozing out and making the floor slick; careful-- you might slip and mess up your future as "the LeBron James of the Bitcoin world" (as your attorney decribed you (18:30), under oath, to a federal judge as part of litigation related to your possession of 3000 BTC taken primarly from members of this forum.).

As miners have created larger blocks F2Pool expirenced high orphaning (>4% according to them); they responded by adding software to mine without transfering or verifying blocks to avoid delays related to transfering and processing block data. Contrary to your claim-- the blocksize limit stems the bleeding here. Their issue is that large blocks take more time to transfer/handle and that they're falling behind as a result. Making blocks _bigger_ would not help this problem, it would do the _opposite_. If a miner wanted to avoid any processing of transaction backlog they'd simply set their minimum fee high and they'd never even mempool the large backlog.

Reasonable minds can differ on the relative importance of difference considerations, but when you're falling all over yourself to describe evidence against your position as support of it-- redefining F2pools crystal clear and plain descption of "large blocks" as their source of problems with the technically inexplicable "full" that you think supports your position, it really burns up whatever credibility you had left. That you can get away with it in this thread without a loud wall of "WTF" just shows what a strange echochamber it has become.

Or maybe death and taxes.

Oh please don't ask and remember I am a naive n00b who doesn't know how to program "Hello world".

what's interesting is that we've never seen it done to the degree it is now.  we had the Mystery Miner a few years ago but he stopped it pretty quick.  also, despite many upgrades added to the protocol previously, we've never had a fork as a result of SPV mining before either.  what's different this time is the consistently full blocks and the fact that Wang Chun told us they create SPV blocks in response to large blocks as a defense.  it seems they consider full blocks large blocks so the excessive SPV mining created last nights fork in light of BIP66 and the upgrade to 0.10.x.  so in that sense, the 1MB cap is the direct cause of what is happening. 

I agree that it could be a positive outcome but I "prefer" my option for 2 reasons:
- The theoretical reason: there's no solution faster than no validation
- The practical reason: from the recent fork, we can see that some (many ?) mining pools prefer no validation than paring down block sizes (e.g. F2Pool mines small or big blocks).

They aren't exactly the same so there's a tiny possibility to break fungibility.  Any serial # beginning with a Y was printed by the Greek central bank... other countries could give their citizens 1 week (say) to exchange any Y notes that made it across the border for equivalent value.  You'd show up at any bank (say) with photo ID and the bills.

Of course the press in Greece could probably be modified to change serial numbers pretty easily...

but Euros are fungible, are they not?

Very dangerous.   ECB could respond by claiming all Y series notes not legal tender.  Of course greece could presumably print other serial numbers easily.  And it could invoke the nuclear option where all greek overseas bank accounts are frozen and ultimately confiscated.  

Where is qoute about double txn validation?  Should be unnecessary...

in case you hadn't noticed; we saw all sorts of these types of gap downs back in 2008. 

absolutely no chance to get out.

According to ZeroHedge, it looks like there might be something to this Euro Banknote Printing Facility in Athens:

http://www.zerohedge.com/news/2015-07-05/greece-contemplates-nuclear-options-may-print-euros-implement-parallel-currency-nati

i don't think so:

I think it's at least 2 guys.

Somebody is buying a lot of bitcoins today.

Remember, there are two issues here: SPV mining empty blocks while you're validating the previous block, and what F2Pool appeared to do that caused the problem: never getting around to actually validating the previous block at all!  

I don't see why SPV mining empty blocks for the short amount of time it takes to validate the previous block is harmful to the network's health (I think it is actually helpful).  

On the other hand, I see what F2Pool did as hurtful to the network, and they were punished accordingly with a loss of 100 BTC.  

This is a self-correcting problem.

but, but pwuille told us that a large block attack from a large miner would choke off small miners! 

don't forget that the top 5 largest miners in the world have inferior connectivity, not superior, like he told us.

i think they're reacting to the larger unconf tx sets being created as a result of the 1MB cap.  they don't want to have to both verify the full blocks coming thru nor construct efficient block sizes from that set.  if the cap was lifted, the unconf tx set should drop in size as faster validating miners can swallow the large unconf sets in one gulp and stuff it into a single block to keep the size of the set down thus discouraging further spamming and the deviant SPV behavior.

yes they will.  and do you blame them?  until the 1MB limit stops jacking up the unconf tx set thru either spamming or real demand, they can't be bothered to go thru the computation to order or pare down this larger than normal set.  SPV is the easiest, simplest way to get around constructing a full block that has the potential to be orphaned.

exactly right.

sometimes it takes a hundred steps to walk across the street.

ok, we've all been lead to believe up to now that validation of tx's had to occur twice by full nodes.  first, upon receipt.  second, upon receipt of the block.  this was crucial to the FUD scare tactic of decrementing full nodes and thus "centralization" we were getting last month by the BS core devs via the "large miner w/ superior connectivity attack on small miners".  now we here about this new mechanism of "pre-validation" that allows tx's to only have to be validated once upon receipt but not necessarily on receipt of a block?

what am i missing?