From: Peter Todd <pete@petertodd•org>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] An initial replace-by-fee implementation is now available
Date: Thu, 9 May 2013 07:46:05 -0400 [thread overview]
Message-ID: <20130509114605.GA28133@savin> (raw)
In-Reply-To: <20130509111913.GA15870@netbook.cypherspace.org>
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
On Thu, May 09, 2013 at 01:19:13PM +0200, Adam Back wrote:
> In this thread discussing this idea
>
> https://bitcointalk.org/index.php?topic=179612.0
>
> it is suggested that the approach risks making 0-confirm double-spends
> easier.
The patch makes the concept of a 0-confirm double-spend obsolete
basically. The model is rather than having some vague, insecure, easily
broken, de-facto no-replacement rule it replaces it with something very
easy to reason about: you are bidding for blockchain space, and you can
adjust your bid after the fact.
The reality is zero-conf double-spends aren't that big of a problem
because the vast majority of payments have other mechanisms they can use
instead of relying on the defacto behavior of dozens of major miners and
nodes.
Long story short, we're better off if we don't give people a false sense
of security.
> I dont see why this should be. Cant part of the validation of accepting a
> fee revision be that every aspct of the revision except the reward must be
> unchanged, otherwise the revision is considered invalid and discarded?
A node has no idea which transaction output is change and which one
isn't; if nodes could distinguish change from payment your privacy would
be badly violated.
By allowing simple replacement without further rules the fee adjustment
process can go on as long as required, without you running out of
additional transaction inputs and without causing the transaction to get
bigger and bigger each time.
It also allows more interesting use cases, like adding additional
outputs to a transaction after the fact as more payees become known, or
if two unrelated parties decide to combine their transactions to save on
blockchain space and preserve their privacy.
Eventually the P2P protocol can have delta compression support, so the
network bandwidth required to merge two transactions into one will be
minimal.
--
'peter'[:-1]@petertodd.org
000000000000014c26728a13e351b4dd7a32e99e28d43a960b5ac5f98696ae5b
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-05-09 11:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-09 9:58 John Dillon
2013-05-09 11:19 ` Adam Back
2013-05-09 11:46 ` Peter Todd [this message]
2013-05-09 12:07 ` Adam Back
2013-05-09 12:20 ` 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=20130509114605.GA28133@savin \
--to=pete@petertodd$(echo .)org \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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