From: Peter Todd <pete@petertodd•org>
To: "Jorge Timón" <jtimon@monetize•io>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory
Date: Thu, 24 Apr 2014 08:59:53 -0400 [thread overview]
Message-ID: <20140424125953.GC16884@savin> (raw)
In-Reply-To: <CAC1+kJM3pSq8YfwbX167rQ0=0Y_hozRQ3pggDN524=LUfOdTqg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3631 bytes --]
On Thu, Apr 24, 2014 at 12:48:54PM +0200, Jorge Timón wrote:
> Here is a solution to the problem of having 0 confirmation
> transactions
FWIW I'm running an experiment right now to detect how easy it is to
doublespend 0-conf transactions I need to collect more data, but initial
results indicate that transaction propagation is sufficiently unreliable
that double-spending frequently works without miners using
replace-by-fee even when both transactions pay high fees, there is a 60
second delay between first and second, and there's only about four
replace-by-fee nodes on the network.
With replace-by-fee scorched-earth the success rate of such
double-spends would be significantly reduced as the attacker would need
to get lucky with bad propagation not just once, but twice in a row.
> that relies on game
> theory and most miners implementing replace-by-fee and child-pays-for-parent.
>
> This has been proposed before
> http://sourceforge.net/p/bitcoin/mailman/message/30876033/
> I'm just going to describe the general idea in more detail.
Just to be clear, while that post is mine, original credit for the idea
actually goes to John Dillon as far as I know; I first heard about it
from him in private discussion.
> Replace-by-fee and child-pays-for parent cannot be prohibited by a
> protocol rule.
> I believe all miners will eventually implement these policies because
> it is the more rational way for them to prioritize transactions.
> Finally I hope they do because it would make 0-confirmation
> transactions possible as described in this post.
> So I can't find any reasoning against replace-by-fee unless my example
> is terribly flawed.
> Am I missing something?
A few things:
1) Replace-by-fee doesn't protect against sybil attacks; only
confirmations are solid evidence that a transaction has actually reached
the mining power and your communication channel to that mining power
isn't being blocked. Keep in mind that Bitcoin depends on the existence
of a jam-free network, and very importantly, lets you detect when that
network has failed and you are being jammed. No unconfirmed transaction
scheme can solve this problem in a decentralized network.
2) Replace-by-fee scorched earth does require you to keep private keys
online to sign the replacements. Not a big deal, but it's yet another
reason why you wouldn't want to use it for high-value stuff.
3) It doesn't directly solve finney attacks(1) where the miner mines the
transaction in private. However finney attacks are only relevant if
there is high centralization of hashing power, and all other proposed
mechanisms, e.g. coinbase reallocation, themselves do a lot of harm to
decentralization. (just look at how coinbase reallocation lets large
pools bully smaller miners out of business by blacklisting their blocks)
One interesting thing with regard to finney attacks and replace-by-fee
though is that enforcing hasher visibility of the blocks they are mining
- what getblocktemplate was meant to do voluntarily - lets any hasher
detect a finney attack double-spend and broadcast it. They have a weak
incentive to do so - the scorched earth reply is a high-fee transaction
of course and pre-broadcasting transactions makes blocks propagate
faster - at which point you're back to a public double-spend. Enforcing
visibility of block contents to hashers is definitely a good thing for
decentralization.
1) https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384
--
'peter'[:-1]@petertodd.org
000000000000000093d8af23978adc9e201a1f2e2dc52844f9013a1da3621572
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-04-24 13:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-24 10:48 Jorge Timón
2014-04-24 11:54 ` Mike Hearn
2014-04-24 12:07 ` Chris Pacia
2014-04-24 12:15 ` Mike Hearn
2014-04-24 14:49 ` Jorge Timón
2014-04-24 15:45 ` Mike Hearn
2014-04-24 17:13 ` Jannis Froese
2014-06-19 3:47 ` Isidor Zeuner
2014-04-25 4:51 ` Gareth Williams
2014-04-25 10:19 ` Mike Hearn
2014-04-25 13:38 ` Gareth Williams
2014-04-24 12:59 ` Peter Todd [this message]
2014-04-24 14:20 ` Jorge Timón
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=20140424125953.GC16884@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jtimon@monetize$(echo .)io \
/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