to mitigate such an attack, how about introducing a fee policy (min relay fee etc.) that is based not only
on the size but also on the number of SIGOPS ?

that doesn't affect the  consensus, obviously.

I mean, if both the block size and the number of SIGOPS in it are a critical resource, then it's only natural to charge for using each of them.

I thought the block transmission time problem was solved by the relay network. The one that
allows miners that found a block  only transmit txs that are not in the mempool.
I'm not sure how widely it's used though.

sure, but if the validation time is reduced to milliseconds then it's a negligible expenditure

do you guys  think that current ASICs or GPUs could speed up block validation?
Currently (as far as I'm aware) bitcoind  only uses CPUs.

May be including GPU support to bitcoind  it could solve the problem, by
simply making verification time negligible.

To implement this attack, non-SPV-mining pools need to waste enough hash power to create a "bad" block. This is profitable to all of them together, but they have to cooperate.  Cooperation seems more difficult to achieve. THen again, if there is one single big pool, the insentive may be big enough for him to do it alone.

It's not difficult to calculate how big it should be; the main unknown paramter is for how long it sends the SPV-miners off to mind the wrong side of the fork.

Thanks for the explanation.

As far as I understand, this is how SPV mining should be done, but not how it was
in this case.  If the miners trusted the new block only during that short window
while it was being propagated, they wouldn't have built a whole new chain on top of it.
At most one block - which would be disbanded once they verified that the block E
they were building on was wrong.

But they didn't check it at all. They just kept on building.

About the cost of the attack: it costs about 25BTC to mine a block.
If it spends 25 000 BTC of other people's money to the attacker's wallet, then
just >0.1% of success makes it worth it.  If major miners are not checking
blocks at all, that probability of success seems to be much higher.

This didn't go very smoothly.
Probably some incentives need to be rethought.

Major pools doing "SPV mining" and trust any block on the longest chain. Really?
That enables pretty obvious attacks  have  a really big disruptive impact.

it's a  weird block.
there are a lot of 0 fee transactions, like this one
which in addition are shown as Doublespends by blockchain.info


why did F2Pool chose to mine these? may be someone found a bug in f2pool and is using
it to doublespend, that is, to cancel some other (unconfirmed) transactions they are sending at the same time
Just a wild guess.

P2Pool is dangerously lagging behind. As usual, for them it's more  difficult to upgrade.

the animation could be interesting if the scale on the left stayed fixed.

the 1001 block window is there precisely not to give the noise much chance.
But it'll get there eventually.

well, I did notice that DZ was last online about a year ago, if that's what you are trying say,

bump. Anybody follows up on this? Any news? Any chances getting anything back at all?

yep, it's AntPool

it seems to me that on this topic it is still original research that is missing, rather than reviews.
That is, what is missing is a formalization of  what it means to achieve a provably secure trustless consensus, and proving that PoW/ PoS/other alternatives achieve/ do not achieve it.  Of course, there may be several stronger/weaker/incomparable notions of such "provably secure consensus", whose merits  and practical applicability could then be argued.

Maybe a proper review of the existing literature is a good start though.

current block size has little to do with real usage.
There are people pushing megabytes of plain text in transactions just for fun.
(example of someone spamming the blockchain with the text of Gavin's rationale for increasing the limit)
These, dust-spammers and tx chains by people who mistakenly think chains
help "mixing" are almost filling the  1 MB limit now, and they can easily   fill 20 MB blocks as well.

Until there is a reasonably-behaved market for transactions, it seems
opportunistic increasing the block size limit, even if the bandwidth/storage are not a problem for most.

I suppose it depends on how significant  the change. is Whether any
used or potentially useful cases are affected.

If the change is mostly techincal then nobody will care.
Look at BIP 66 voting that is going on now.  Nobody seems to care very much.

Like I said, if it requires a specialized tool to get it out, then it can be ignored.

I mean, the blockchain probably contains your username already: there's an A at some place, M at some other, etc.
I can publish a tool that finds  it in the blockchain, but the tool would be longer than the piece of data in question (your username).


large chunks of plaintext, on the other hand, is a different matter.

why are you saying it cannot be disallowed?

this is ugly.
I mean, obviously there will always be ways to embed data into the blockchain;
but if one has to split them between a long chain of transcations, and also encode them somehow inside,
 then the information (and effort)  needed to extract the data is non-neglible, so one can ignore it.

But the possibility of  pushing large chuncks of plain text in a single transaction
looks like a bug to me.

Is it possible to make this kind of things non-standard, without compromising the
expressive power of the script? Like, the way those SASSAMA/ Bernanke ASCII pictures
were put was somehow "outlawed" later on.

link to the P2SH techinque?
the data is basically in plain text?

what's the daily volume of these?