hmm interesting that the Bitcoin dumping started when these guys went down eh..

Note that the problem might arise also by a bug / accident and not as an attack.

Since value spent is not part of the signature it is easy to create an arbitrary fee by a defective wallet software.
Collecting that huge fee might provide a higher incentive to miner than the block subsidy on the trunk.

Assuming miner are fully rational, they might even form a temporary coalition to claim the fee:
The miner who mines forking block might offer part of the fee gained in a similar transaction to
other miners, so they help to extend his fork. A sufficiently high stake could trigger a long
fork “battle” of ad-hoc coalitions.

Addressing the known bug of the signature hash, that it does not include the value spent,
would have other positive effects, e.g. for resource limited hardware wallets.

Interpretation of an OP_NOP for a value hashing signature check were suggested by Alan Reiner
discussed earlier on bitcointalk.

Tamas Blummer

If I had a woman in there to be honest I could live without internet for a year lol!

I'd prefer to be paid in bitcoins.

I could then immediately convert some of the bitcoins to fiat myself if I found that I still needed to use some fiat.  At least that way, I'd be in control of what the percentage was that was converted to fiat with every payment received.

where is my update ?

It is clear by the new title that this thread has degraded into Muddafudda and Spoetniks pissing ground.

Thats the whole point of f5 steganography. It blends in with the preexisting jpeg compression algorithm making it harder to detect. The next bit though is the part that blows you away. Even if you know there is data encoded in the picture, your going to need to figure out how its encoded and then comes the challenge of decryption. It's not just steganography.

Also there is more than one particular steganographic method, so the first hurdle is compounded by trying to figure out what method to look for.

i did see your point, and the point the op made. then i thrashed it out into a few scenario's and see the discrepancies that you described along with a few other i thought up, and simply dismissed the theory. i then thought about a different scenario where a delay/freeze would be possible.

i am not saying your wrong, but in practical terms i cant see the theory happening of a permanent chain freeze without total network collusion... as you say, too many variables.

I've heard about this idea from TierNolan. Here's some quick an dirty analysis:

Suppose the last known block claimed a large tx fee of L. A miner who owns 1/N of the total hashrate needs to choose between two strategies:

1. Mine on top of that block and win usual reward R with probability 1/N.
2. Mine on top of the previous block, trying to make two blocks in a row, might get reward L with probability 1/N^2.

Thus for the first strategy expected payoff is R/N, and for the second the expected pay-off is L/N^2.

Second strategy is viable if R/N < L/N^2,
 R < L/N.

Now suppose the miner who claimed the unusually large reward will share it with the next miner, for example, using coinbase output with OP_TRUE. If that shared reward Rs is higher than L/N^2, then the next miner will be better off mining on top of that block.

This doesn't require protocol changes(*) and can be simply incorporated into a piece of code which decides what to do when a transaction with unusually large fee appears. (I.e. it will automatically share the fee, and others will recognize that). And if the biggest miner has 25% of all hashrate, sharing 25% of your loot doesn't sound that bad.

(*) Except one problem: coinbase maturity rules won't allow one to share the fee with the next miner.
So some protocol changes are required. But changes which affect coinbase maturity and sharing are probably going to be simpler and smaller than what Sergio have proposed.

90% wrong

large fee's dont cause freezes all by themselves. there have been cases in the past where a few people messed up their raw transactions and had a high fee, and guess what happened.. nothing unusual apart from the fact that the sender messed up and lost his bitcoin.

the only possible way to perform a successful freeze is to fill up a block with a single transaction with 4000 outputs (1mb data) and a very tempting fee to co-erce miners to accept their TX and ignore everyone elses, thus delaying other tx's.

the fee itself or miners wont be the cause of a freeze. but the transaction with 1mb datasize being accepted would..

the freezing does not last several blocks or hours.. mining still continues every 10 minute on average. but if a whale can continually throw large fee's and make 1mb transactions, and miners continue to choose to accept the transaction. then all other transactions will have to wait until there is a gap.

also to note that miners prefer to deal with tx's of just quarter of a mb or less, just to get a block solved faster than the other pool. (less data= better solve time)
thus the unethical whale wasting bitcoins would need a rather large tempting fee, and still no guarantee's miners will accept it.

Panic selling always pushes the price as far as it can go, you can count on it that we are at tough support here. count how many bitcoins have been sold over the down trend. A small order like 20k bitcoin is easily absorbed over the exchanges.

what? zero innovation?
you know another coin with a mobile app for steganography
Through this app, you can send coins anonymously by sms, hidden in a pic.
If the message was intercepted, the only thing that will appear for NSA, is that a photo has been submitted 

NO.

I should point you to some of the tools that have been discussed in
the past which are potentially helpful here:

The first is the use of locktime on normal transactions. This
behavior is already in Bitcoin core git: The idea is that users of
the system should locktime their transaction at a point as high as
they expect it to get included. If used well this means that there
should always be a base of fees which can only be collected by future
blocks, creating an incentive to move forward. This may be
particularly effective if the limitations on blocksize mean that there
is always a healthy standing load.

The second is having block commitments in transactions
(https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas). The idea is that
the data under signature in a transaction could commit to some recent
block which _must_ be in the chain or the transaction's fee cannot be
collected (or, at least, not all of the fee). This would allow
transacting users to 'vote with their fees' on the honest chain.
Arguably this could also be used to pay for doublespending forks, but
you can already do that by paying fees via a chain that stems from the
doublespend. This greatly complicates strategy for forking miners,
since future transactions which you haven't even seen yet may have
fees conditional on the honest chain.

I think both of the above are obviously useful, should be done, but
don't completely address the concern, they may be adequate.

The third is fee forwarding. An example form would be that the miner
gets half the fees, the rest are added to a pool which pays out half
in every successive block. This can prevent unusually high fees from
making as much reorg pressure and more correctly models what people
would like to pay for: getting their txn buried. The huge problem
with this class is that miners can demand users pay fees "out of
band", e.g. with additional txouts (just make a different version of
the tx for each miner you wish to pay) and escape the process. I have
had some notions about fees that come in the form of adjusting the
difficulty of creating a block slightly (which is something that can't
be paid out of band), but such schemes becomes very complicated very
fast. I am unsure if any form of fee forwarding is workable.

Something you might want to try to formalize in your analysis is the
proportion of the network which is "rational" vs
"honest"/"altruistic". Intuitively, if there is a significant amount
of honest hashrate which is refusing to aid the greedy behavior even
at a potential loss to themselves this strategy becomes a loser even
for the purely greedy participants. It would be interesting to
characterize the income tradeoffs for different amounts of altruism,
or whatever convergence problems an attempt by altruistic
participaints to punish the forkers might create.