Yes, you're right. I didn't consider that case. But the problem is that
this is not automatic. Currently there is a clear division between
miners how will not take the kickback (irrrational) and miners who will
(rational).
This seems to come up a lot. Your definition of rational is a short
On 06/10/2014 08:43 p.m., Tom Harding wrote:
On 10/5/2014 4:00 PM, Sergio Lerner wrote:
If everyone acts rationally in his own interest, then the best choice
for the remaining miners is to try to mine a competing block at the
same height n including the high-fee transaction, to collect the
On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner sergioler...@certimix.com wrote:
Using the my previous terminology, automatic fee-sharing (ORBS) is a
solution to the freeze problem (FRONT) but opens the windows to
CHAKIDO double-spending. and CHAKIDO double-spending is a much worse
problem than
On 07/10/2014 04:16 p.m., Gregory Maxwell wrote:
Then I spend the output of the fraudulent spend nlocked
one block higher, and spend the output of that one again, nlocked one
block higher, and so on... each step paying fees.
Yes, you're right. I didn't consider that case. But the problem is
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
I would like to share with you a vulnerability in the Bitcoin protocol
I've been thinking of which might have impact on the future of Bitcoin.
Please criticize it!
*The Freeze on Transaction Problem
*
The freeze problem occurs if someone publishes a transaction with fees
much higher than the
On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner sergioler...@certimix.com wrote:
I would like to share with you a vulnerability in the Bitcoin protocol I've
been thinking of which might have impact on the future of Bitcoin. Please
criticize it!
The Freeze on Transaction Problem
I should point
On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell gmaxw...@gmail.com
I should point you to some of the tools that have been discussed in
the past which are potentially helpful here:
Ah, I should also mention a somewhat more far out approach which helps
here as a side effect:
If transactions were
On Sun, Oct 5, 2014 at 4:54 PM, Jorge Timón jti...@blockstream.io wrote:
In any case, it is interesting to think about this things since mining
subsidies will eventually disappear and then transaction fees will
ALWAYS be higher than subsidies.
You can imagine that instead of subsidy Bitcoin
On Mon, Oct 6, 2014 at 1:40 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
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
14 matches
Mail list logo
