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.
the block size being lower than the instant offered demand (there is
always a backlog) are both things which address the concern of this thread.
:)
I'm skeptical such a situation can ever be stable. People have no incentive
to create a transaction that will remain stuck in the backlog
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
Comments between lines...
On 06/10/2014 03:42 a.m., Alex Mizrahi wrote:
.
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,
Sergio,
you can call this an ORBS attack or an attempt of ad-hoc coalition forming for
a fork.
Preparation Step:
Include a transaction sending a sizable amount between two of your own
addresses in every block.
Miner can do this at zero cost in their own blocks.
Execution:
Embed into the
5 matches
Mail list logo
