public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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: Tue, 7 Oct 2014 19:16:13 +0000	[thread overview]
Message-ID: <CAAS2fgRdB_4XS9Q+MFLsNtXvSiYS9Ymh9SAPzcJ5aae+89vxFA@mail.gmail.com> (raw)
In-Reply-To: <54343948.1030400@certimix.com>

On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner <sergiolerner@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 FRONT.

I'm not following this. Perhaps I'm getting lost in terminology here.

It's already to provide double spending bounties to greedy-rational
miners, via a simple approach that has been known since at least early
in 2011.    I pay someone then create a later fraudulent doublespend
which is nlocked at the height the original payment occurred, paying
large fees. 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.

A hypothetical purely greedy miner which considers all sequences of
acceptable forks and transactions would see that they have higher
expected returns assisting the theft (assuming the honest party
doesn't fight back by also adopting a similar strategy), at least if
the population of greedy miners is large relative to altruistic ones.

I don't see how miners being able to roll forward fees makes anything
worse, since the transactions themselves can also roll forward fees.



  reply	other threads:[~2014-10-07 19:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <543438E4.8080501@certimix.com>
2014-10-07 19:04 ` [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT) Sergio Lerner
2014-10-07 19:16   ` Gregory Maxwell [this message]
2014-10-07 20:04     ` Sergio Lerner
2014-10-08 10:19       ` Mike Hearn
2014-10-05 23:00 Sergio Lerner
2014-10-05 23:40 ` Gregory Maxwell
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

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=CAAS2fgRdB_4XS9Q+MFLsNtXvSiYS9Ymh9SAPzcJ5aae+89vxFA@mail.gmail.com \
    --to=gmaxwell@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=sergiolerner@certimix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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