From: Mike Hearn <mike@plan99•net>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
Date: Wed, 17 Apr 2013 11:48:59 +0200 [thread overview]
Message-ID: <CANEZrP0z6W0ZDsytQ7Rcqb5L6rswn1wv8cbR7c383Dmpzu+gyg@mail.gmail.com> (raw)
In-Reply-To: <453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com>
[-- Attachment #1: Type: text/plain, Size: 3084 bytes --]
When this system was first being discussed, Gavin was concerned that miner
incentives were to ignore replacements because it meant extra work and the
replacement might have equal or lower fees than before (or indeed, no
fees). He proposed two solutions: one is to progressively raise the fee on
each replacement. The other is to specify lock time in terms of blocks and
then step it backwards once for each replacement, thus ensuring that by
replacing the transaction you get to claim any attached fee earlier.
It should be apparent that both solutions can be implemented by whichever
application is running the contract - the core Bitcoin network and software
is agnostic either way.
Now, Gavin and I disagreed on whether this would actually be necessary. As
I already pointed out, both solutions seriously reduce the utility of HFT
because they limit how often you can update the contract. Instead of an
online game billing you per second, maybe it can only do it per minute or
per 10 minutes with the lock time solution because otherwise you run out of
blocks, and with ever-increasing fees perhaps the contract becomes too
expensive to justify after a while.
So it'd be nice if this ended up not being necessary. Experience indicates
that rational miners typically don't pursue a short-termist
profit-at-any-cost agenda - free transactions have always been included in
blocks, miners include transactions even though you could avoid a lot of
complexity by just not including any at all, etc. Some miners like BTC
Guild have actually sacrificed significant amounts of money for the good of
the system. You can see this in terms of rational self interest - miners
earn Bitcoins thus it's in their interest for Bitcoins to be as useful as
possible, as that is what gives them value. Or you can see it in terms of
ideologically-driven altruism. Or both.
If I were to implement an application that used tx replacement, I would
probably start with replacements that don't change the fees and don't count
down the lock time field. We can then observe whether miners bother
changing their software to behave differently, or whether the inherent
utility of the application is enough to convince them to play by the
default rules. Ideally at least one application made possible by this
feature is a "killer app" - something so useful / unique / compelling that
people want to obtain Bitcoin just to use it. If someone can find such an
app, then rational miners should want tx replacement to work as reliably as
possible because it boosts the value of their earnings.
There are some other misc details - reactivation requires that we bump the
protocol version and start relaying non-final transactions to new nodes
again. Those nodes should relay replacements but not let them enter wallets
unless/until the wallet software itself can handle them better, for
instance, by communicating via APIs anticipated confirmation times. This is
something for individual wallet APIs to handle on their own, and just
ignoring non-final transactions is a perfectly workable approach for
Bitcoin-Qt.
[-- Attachment #2: Type: text/html, Size: 3322 bytes --]
next prev parent reply other threads:[~2013-04-17 9:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-16 17:39 Mike Hearn
2013-04-16 18:43 ` Peter Todd
2013-04-17 9:48 ` Mike Hearn [this message]
2013-04-17 19:44 ` Alan Reiner
2013-04-18 6:07 ` John Dillon
2013-04-18 8:14 ` Peter Todd
2013-04-19 4:38 ` John Dillon
2013-04-19 4:55 ` Jeff Garzik
2013-04-18 8:32 ` Mike Hearn
2013-04-18 9:04 ` Peter Todd
2013-04-18 9:28 ` Peter Todd
2013-04-18 9:32 ` Mike Hearn
2013-04-18 9:28 ` Mike Hearn
2013-04-18 9:34 ` Mike Hearn
2013-04-18 10:08 ` Peter Todd
2013-04-18 10:19 ` Mike Hearn
2013-04-18 13:37 ` Gavin Andresen
[not found] ` <CAD0SH_WOG8jQvzsNzwud3fYjaxqTJo0CS7yP6XZeKvap_yqtqg@mail.gmail.com>
2013-04-17 9:19 ` Mike Hearn
2013-04-20 1:48 Jeremy Spilman
2013-07-18 11:13 ` Peter Todd
2013-07-18 12:53 ` Jeff Garzik
2013-07-18 13:43 ` Peter Todd
2013-07-18 16:09 ` Peter Todd
2013-04-20 20:51 Jeremy Spilman
2013-04-22 11:07 ` Mike Hearn
2013-04-23 12:40 ` John Dillon
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=CANEZrP0z6W0ZDsytQ7Rcqb5L6rswn1wv8cbR7c383Dmpzu+gyg@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/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