From: Gregory Maxwell <gmaxwell@gmail•com>
To: Sergio Lerner <sergiolerner@certimix•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
Date: Sun, 5 Oct 2014 16:40:43 -0700 [thread overview]
Message-ID: <CAAS2fgQ-MrmBGjcuqYdvfs0g2b6+vAOVR3sUCCyQy386CY8EDA@mail.gmail.com> (raw)
In-Reply-To: <5431CD8D.7050508@certimix.com>
On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner <sergiolerner@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 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.
next prev parent reply other threads:[~2014-10-05 23:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-05 23:00 Sergio Lerner
2014-10-05 23:40 ` Gregory Maxwell [this message]
2014-10-05 23:50 ` Gregory Maxwell
2014-10-05 23:54 ` Jorge Timón
2014-10-06 0:01 ` Gregory Maxwell
2014-10-06 11:02 ` Mike Hearn
2014-10-06 12:22 ` Tamas Blummer
2014-10-06 6:42 ` Alex Mizrahi
2014-10-06 13:21 ` Sergio Lerner
2014-10-06 13:29 ` Tamas Blummer
[not found] <543438E4.8080501@certimix.com>
2014-10-07 19:04 ` Sergio Lerner
2014-10-07 19:16 ` Gregory Maxwell
2014-10-07 20:04 ` Sergio Lerner
2014-10-08 10:19 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAS2fgQ-MrmBGjcuqYdvfs0g2b6+vAOVR3sUCCyQy386CY8EDA@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=sergiolerner@certimix$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox