public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] double-spend deletes (or converts to fees) (Re: reward for making probabalistic double-spending via conflicting transactions easy)
Date: Wed, 15 May 2013 15:00:14 +0200	[thread overview]
Message-ID: <20130515130014.GA6156@netbook.cypherspace.org> (raw)
In-Reply-To: <20130515113827.GB26020@savin>

On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote:
>no-one seems to think much about how in practice very few vendors have a
>setup to detect if conflicting transactions were broadcast on the network
>simultaneously - after all if that is the case which transaction gets mined
>is up to chance, so much of the time you'll get away with a double spend. 
>We don't yet have a mechanism to propagate double-spend warnings, and funny
>enough, in the case of a single txin transaction the double-spend warning
>is also enough information to allow miners to implement replace-by-fee.

About double-spends it might be better if the double-spend results in no-one
keeping the money ie it gets deleted by definition (except for the fees, or
the whole payment gets converted into a 0BTC output so 100% fees).  Ideally
you'd want a way for known double spends to be circulated at priority in the
p2p network, even routed directly to earlier recipients if known.  However
have to watch out for even the fees being double spent in other
transactions.  Maybe the fees could be demanded to be self-created (no
trusted green-coin issuer) 6-confirmation spend-to-miner green-coins.

(Note double spends are not-binary.  An attacker can spend a 25BTC coin via
50x 1BTC transactions.  Which 25 are valid?  Currently it is the first 25
from the network perspective of the miner that succeeds on the current
block.  (And that view overrides, even if other miners had differing views,
unless the block later becomes an orphan).  Its surely easy for a double
spender to accumulate fast connections to known powerful miners to get the
spends that benefit him to them first.)

In that way (with double-spend deletes) the would be double-spender can not
gain within the bitcoin protocol by double spending.  He can gain outside of
the protocol eg by persuading merchants to give him non-revocable resellable
non-physical goods (or physical but anonymous goods).  But that is harder
work, and people selling goods with no recourse will be defensive about
confirmations.

ps I still dont think replace-by-fee is a good idea, at least the way it was
implemented with changeable outputs, but I think that discussion seemed
closed, so I wont rehash it.

Adam



      parent reply	other threads:[~2013-05-15 13:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-15 11:38 [Bitcoin-development] 2BTC reward for making probabalistic double-spending via conflicting transactions easy Peter Todd
2013-05-15 12:19 ` Peter Todd
2013-05-15 13:31   ` Alan Reiner
2013-05-15 12:41 ` Melvin Carvalho
2013-05-15 13:00 ` Adam Back [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=20130515130014.GA6156@netbook.cypherspace.org \
    --to=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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