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 08:20:05 -0400 [thread overview]
Message-ID: <20130509122005.GA6645@savin> (raw)
In-Reply-To: <20130509120722.GA16188@netbook.cypherspace.org>
[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]
On Thu, May 09, 2013 at 02:07:23PM +0200, Adam Back wrote:
> I have to say I do not think you want to have it be random as to who gets
> paid (by having conflicting double spends floating around with different
> payee & change addresses all from the same sending address.)
Indeed. That's the point of the blockchain, to take all those potential
inconsistencies and vote on a true transaction history to achieve
consensus.
> About current defacto no replacement: it is the best bitcoin currently has,
> and it has value, with it you need to do a net-split to attack eg
> 1-confirmation, and this proposal weakens it. Net-splits are possible but
> not trivial. This proposal moves them into spec - ie free.
Right now we don't have double-spend proof propagation, so the
"net-split" attack is actually totally trivial: just broadcast two
different, mutually incompatible, transactions at the same time. About
half the time the recipient will get the payment, the other half of the
time the payment they thought they were going to get is invalidated.
It's very, very rare for sites to have protection against that;
blockchain.info's shared-send mixer is one of the few exceptions. But
the have access to a whole network monitoring service with connections
to nodes all over the planet.
> About privacy: I think you are going to inherently disclose which is the
> change address, because you will decrease the change when you increase the
> fee. There is no coin management in the client, and as far as I saw so far,
> no privacy management of which coins to reduce coin cross linking. Who's to
> say the client has 100s of times as many coins as the payment.
>
> If people dont want to reveal which is change and which payment, they need
> to put a big enough fee up front based on a margin over prevailing fee
> statistics.
It's not ideal, but it still protects against after-the-fact blockchain
analysis.
Statistics is hard - you can't get it right all the time. Besides, what
happens when everyone adds a safety margin? Some people can afford to
wait, so for them starting at a low bid and raises it makes a lot of
sense.
> Also if the bids are too flexibly different how do you stop both bids being
> processed (eg one in a block, the next in the next block).
Think about that problem a bit harder. :)
--
'peter'[:-1]@petertodd.org
00000000000000220dc3b283e651068535f8e934096cfef35342bc688d8ee578
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
prev parent reply other threads:[~2013-05-09 12:20 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
2013-05-09 12:07 ` Adam Back
2013-05-09 12:20 ` Peter Todd [this message]
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=20130509122005.GA6645@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