public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Daniel Rice <drice@greenmangosystems.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Lawrence Nahum <lawrence@greenaddress.it>
Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees
Date: Mon, 16 Jun 2014 16:50:41 -0400	[thread overview]
Message-ID: <20140616205041.GA21784@savin> (raw)
In-Reply-To: <CAFDyEXistfW2Y-93ipty_Z5NgtqT_1BRUNqBsYQNRFz_GjOQ6w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]

On Mon, Jun 16, 2014 at 01:37:52PM -0700, Daniel Rice wrote:
> True, that would work, but still how are you going to bootstrap the trust?
> TREZOR is well known, but in a future where there could be 100 different
> companies trying to release a similar product to TREZOR it seems like one
> company could corner the market by being the only one that is an accepted
> instant provider at most vendors. It seems to encourage monopoly unless
> there is a standard way to bootstrap trust in your signature.

You can always use fidelity bonds, or as I called it at the time(1),
"Trusted identities":

    Lets suppose Alice has some bitcoins held at bitcoin address A. She
    wants to establish trust in the "identity" associated with the ECC
    keypair associated with A, for instance for the purpose of having other
    users trust her not to attempt to double spend. Since the trust she
    seeks is financial in nature, she can do this by valuing the identity
    associated with A, by delibrately throwing away resources. A simple way
    to do this would of course be to transfer coins to a null address,
    provably incurring a cost to her.

    A more socially responsible way would be for her to create a series of
    transactions that happen to have large, and equal, transaction fees.
    Bitcoin makes the assumption that no one entity controls more than 50%
    of the network, so if she makes n of these transactions consecutively,
    each spending m BTC to transaction fees, there is a high probability
    that she has given up at least n/2 * m BTC of value. This of course is
    all public knowledge, recorded in the block chain. It also increases the
    transaction fees for miners, which will be very important for the
    network in the future.

    Now Bob can easily examine the block chain, and upon verifying Alice's
    trust purchase, can decide to accept a zero-confirmation transaction at
    face value. If Alice breaks that promise, he simply publishes her signed
    transaction proving that Alice is a fraudster, and future Bob's will
    distrust Alice's trusted identity, thus destroying the value needed to
    create it.

    In effect, we now have a distributed green address system.

Note that the second paragraph is seriously obsolete - better to either
use announce-commit sacrifices, or much preferably, simple destruction
of coins. (sacrifice to fees encourages mining centralization for
obvious reasons)

1) "[Bitcoin-development] Trusted identities", Apr 26th 2012, Peter Todd,
   http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg01005.html

Incidentally, my first post to this mailing list!

-- 
'peter'[:-1]@petertodd.org
000000000000000058ca7ee3a40438ea5a96e499910638352468c6d69abdb226

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

  parent reply	other threads:[~2014-06-16 20:50 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-14 12:00 [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Lawrence Nahum
2014-06-14 12:57 ` Andreas Schildbach
2014-06-15  9:22   ` Lawrence Nahum
2014-06-15 12:46     ` Andreas Schildbach
2014-06-15 14:09       ` Lawrence Nahum
2014-06-18 12:09       ` Lawrence Nahum
2014-06-18 13:25         ` Mike Hearn
2014-06-18 15:59           ` Daniel Rice
2014-06-18 16:09             ` Mike Hearn
2014-06-19 17:36               ` Daniel Rice
2014-06-25 14:01         ` sebastien requiem
2014-06-16 12:19 ` Mike Hearn
2014-06-16 12:25   ` Mike Hearn
2014-06-16 15:09   ` Daniel Rice
2014-06-16 15:26     ` Lawrence Nahum
2014-06-16 16:00       ` Daniel Rice
2014-06-16 16:07         ` Mike Hearn
2014-06-16 15:41     ` Paul Goldstein
2014-06-16 15:48       ` Mike Hearn
2014-06-16 16:30         ` Lawrence Nahum
2014-06-16 16:45           ` Mike Hearn
2014-06-16 16:56             ` Lawrence Nahum
2014-06-16 17:01               ` Mike Hearn
2014-06-16 17:16                 ` Lawrence Nahum
2014-06-16 18:02                   ` Alex Kotenko
2014-06-16 18:09                     ` Mike Hearn
2014-06-16 20:29                       ` Daniel Rice
2014-06-16 20:32                         ` Mike Hearn
2014-06-16 20:37                           ` Daniel Rice
2014-06-16 20:46                             ` Mike Hearn
2014-06-16 20:53                               ` Daniel Rice
2014-06-16 20:55                                 ` Mike Hearn
2014-06-16 20:50                             ` Peter Todd [this message]
2014-06-16 21:02                         ` Daniel Rice
2014-06-16 20:32                       ` Alex Kotenko
2014-06-16 17:44                 ` Jorge Timón
2014-06-17 15:58                 ` Isidor Zeuner
2014-06-18  1:39         ` Tom Harding
2014-06-17 15:58     ` Isidor Zeuner
2014-06-18  9:15       ` Mike Hearn
2014-06-18 20:47       ` Natanael
2014-06-18  2:01     ` Tom Harding
2014-06-16 15:28   ` Lawrence Nahum
2014-06-16 15:43     ` Mike Hearn
2014-06-16 17:05       ` Lawrence Nahum
     [not found] <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net>
2014-06-17 20:40 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Goss, Brian C., M.D.
2014-06-17 22:28   ` Mark Friedenbach

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=20140616205041.GA21784@savin \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=drice@greenmangosystems.com \
    --cc=lawrence@greenaddress.it \
    /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