From: Daniel Rice <drice@greenmangosystems.com>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Lawrence Nahum <lawrence@greenaddress.it>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
Date: Wed, 18 Jun 2014 08:59:44 -0700 [thread overview]
Message-ID: <CAFDyEXhY-KxM6dN0ngXiiB4ga85tD6e4gW6QVpST5XxJARLicw@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0ekAHNOHha_8ncu_QKVCidBQndw2x0+5rciD92LdOS7A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]
> I'm not sure this is actually important or useful; trusting someone not
to double spend is a pretty binary thing
I think that's true if you assume that the instant provider list is based
on a by hand created list of accepted instant providers. That's how VISA
works now and that's why I was asking for an approach where the
trusted_instant_providers list is scalable because that seems very
dangerous.
Since you can detect when a double spend happens, the entire instant
provider list could be automatically generated based on a 3rd party network
that shares information between vendors and also monitors double spends. In
that scenario, there is no hand written exclusive list of accepted instant
providers. There is just a database of past history on all instant
providers. That database can be used to give a confidence score for a
specific instant provider for a given transaction amount. In this scenario,
a new wallet company would be able to earn trust over time. If the list is
made by hand, "Bitpay accepts Circle, Coinbase, and GreenAddress for
instant transactions", then new wallet providers have to go around bribing
Bitpay and the other large merchant transaction providers to get on their
instant provider list.
Allowing more than one instant signature on a transaction is supposed to
help avoid that scenario. For example, lets say I want to establish my own
instant signature. I use a wallet that already has an accepted instant
signature, but it also allows me to add my own instant signature. I do this
so that I can start establishing trust in my own instant signature while
relying on their instant signature.
On Wed, Jun 18, 2014 at 6:25 AM, Mike Hearn <mike@plan99.net> wrote:
> - allowing multiple signatures ?
>
>
> I'm not sure this is actually important or useful; trusting someone not to
> double spend is a pretty binary thing. I'm not sure saying "you need to get
> three independent parties to sign off on this" is worth the hassle,
> especially because the first signature is obvious (your risk analysis
> provider or hardware) but the second and third are ..... who? Special
> purpose services you have to sign up for? Seems like a hassle.
>
> But it's up to you.
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 4026 bytes --]
next prev parent reply other threads:[~2014-06-18 15:59 UTC|newest]
Thread overview: 46+ 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 [this message]
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 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Peter Todd
2014-06-16 21:02 ` [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 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
2014-06-16 8:53 Daniel Rice
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=CAFDyEXhY-KxM6dN0ngXiiB4ga85tD6e4gW6QVpST5XxJARLicw@mail.gmail.com \
--to=drice@greenmangosystems.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=lawrence@greenaddress.it \
--cc=mike@plan99.net \
/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