From: Peter Todd <pete@petertodd•org>
To: John Dillon <john.dillon892@googlemail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] Zeroconf-safe tx replacement (replace-for-fee)
Date: Mon, 4 Nov 2013 05:52:43 -0500 [thread overview]
Message-ID: <20131104105243.GA28805@savin> (raw)
In-Reply-To: <CAPaL=UVnfVkU_mbQKE2gg7RXBv+B13A1eHU4VpiHkBdmfea80g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]
On Mon, Oct 28, 2013 at 07:17:50AM +0000, John Dillon wrote:
> This discussion seems to be a lot of hot air over a simple observation that
> estimates are imperfect and always will be. I do not understand you vehement
> opposition the notion that a backup is a good thing except in the context that
> replacement to change fees is halfway to profit-seeking replacement by fee.
>
>
> Peter Todd:
>
> You did a fair bit of leg work for replace-by-fee. Seems to me that
> replace-for-fee will help prep infrastructure to eventual replace-by-fee usage,
> while avoiding some of the politics around zero-conf transactions.
Here's the easy part done:
https://github.com/petertodd/bitcoin/tree/replace-for-fee
The rules are pretty simple: a replacement can only happen if every
output in the old transaction has a corresponding output in the new with
the same scriptPubKey, and of equal or greater value. All old tx outputs
must also be unspent. For implementation reasons, the order of the
outputs must also be the same, and the code will never replace two
transactions with one.
If someone wanted to mine with the above code, I'd say go right ahead.
(modulo general testing concerns)
Client-side though it shows a flaw with the Bitcoin wallet code that I
should have realized months ago: essentially a transaction in your
wallet with double-spent inputs forever blocks those inputs from being
spent. This doesn't happen too often because you're wallet will
currently never create double-spends, and will never respend unconfirmed
coins from someone else, but any CoinJoin implementation violates that
assumption and an attacker could easily cause a lot of havok.
I'll have to think about the issue further, but essentially the wallet
needs to recognize when a transaction's inputs no longer exist, and mark
the remaining inputs as unspent. Actually deleting those transactions
from your wallet is secondary to that more important concern.
--
'peter'[:-1]@petertodd.org
000000002fdfe6bbcffea72c934475cd4fcfe78d8d06910016d707c9b4a9e827
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2013-11-04 10:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-24 14:30 [Bitcoin-development] Making fee estimation better Peter Todd
2013-10-24 14:38 ` Mike Hearn
2013-10-24 14:43 ` Peter Todd
2013-10-24 14:46 ` Mike Hearn
2013-10-24 14:54 ` Peter Todd
2013-10-24 20:39 ` Gavin Andresen
2013-10-25 7:07 ` Peter Todd
2013-10-25 12:02 ` Andreas Petersson
2013-10-25 13:29 ` Mark Friedenbach
2013-10-25 14:08 ` Andreas Petersson
2013-10-25 16:13 ` Peter Todd
2013-10-25 19:35 ` Jeremy Spilman
2013-10-25 22:13 ` Peter Todd
2013-10-25 7:51 ` Jeremy Spilman
2013-10-25 22:49 ` Peter Todd
2013-10-26 0:25 ` Gavin Andresen
2013-10-26 7:28 ` Peter Todd
2013-10-28 7:17 ` John Dillon
2013-11-04 10:52 ` Peter Todd [this message]
2013-11-04 11:10 ` [Bitcoin-development] Zeroconf-safe tx replacement (replace-for-fee) Adam Back
2013-11-04 11:59 ` Peter Todd
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=20131104105243.GA28805@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=john.dillon892@googlemail$(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