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: Mon, 16 Jun 2014 14:02:45 -0700 [thread overview]
Message-ID: <CAFDyEXghQ0yOpsoj2T4535m1XdKsdg6993hmp8iZQDy0ixRsQg@mail.gmail.com> (raw)
In-Reply-To: <CAFDyEXg8OnoYCNLT1WeX2tBPTB_zcXsZ6ujP_8YmPvGyf4pzkw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4080 bytes --]
Mike Hearn <mike@plan99•net> wrote:
>> A more scalable approach would be for the user to send the name and
>> signature of their "instant provider" every time and the merchant just
>> chooses whether to ignore it or not, but as Lawrence points out, this is
>> incompatible with the provider charging extra fees for "instantness". But
>> should we care? I'm trying to imagine what the purchasing experience is
like
>> with optional paid-for third party anti-double-spend protection.
Ultimately
>> it's the merchant who cares about this, not me, so why would I ever pay?
Lawrence Nahum <lawrence@greenaddress•it> wrote:
> I think you are wrong here.
> Just because up to date credit cards charged the merchant which in turn
> charged you and the ordinary cash payer doesn't mean a newer and better
> system can't be transparent from day one.
I don't think a whitelist of trust is a practical approach because you are
going to want to have varying levels of trust in different instant
providers. This would be based on how large their past transaction volume
has been. For that reason maybe another approach is an additional
negotiation message between the merchant and wallet. Merchant sends payment
details -> wallet responds with their instant information requesting if an
instant transaction will be accepted for this transaction. Merchant weighs
the risk based on historical data about this particular instant provider
and the amount of the requested transaction -> Merchant responds yes or no.
That approach avoids the scaling issue, but also allows for Lawrence's use
case of charging the user a fee only in the case where the instant
transaction is supported.
On Mon, Jun 16, 2014 at 1:29 PM, Daniel Rice <drice@greenmangosystems•com>
wrote:
> I'm trying to think through how to encourage the maximum number of instant
> signature providers and avoid the VISA monopoly. Ideal case would be that
> people can even be their own instant provider.
>
> What if the protocol allowed multiple instant signatures on a transaction?
> Would it encourage more instant providers? For example, a new instant
> provider could bootstrap their own trust by paying an already trusted
> instant provider to co-sign the same transaction. This would be useful in
> the case that a new company tries to release a new wallet once the trust
> ring is already established. Nobody will use that wallet because it does
> not have the trusted history to do instant transactions, but if they can
> pay a small amount per transaction to a third party to cosign, they can
> build trust in their own signature till they can eventually have enough
> trust on their own. This could be how an individual user could grow trust
> in their own instant signature as well.
>
>
> On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn <mike@plan99•net> wrote:
>
>> I think many of us feel it'd be better if this kind of thing were not
>> needed at all, however, the best way to ensure it doesn't end up being used
>> is to write code, not to try and block alternative approaches. If Bitcoin
>> is robust the market should sort it out. If it's robust for some
>> transactions and not others, that makes for a fun project for a future
>> generation of hackers to sort out.
>>
>> OK, enough philosophy - let's try and keep this thread just for
>> discussion of the BIP itself from now on. If you'd like to continue
>> debating the Future of Bitcoin please change the subject line and break it
>> out into a new thread.
>>
>>
>> ------------------------------------------------------------------------------
>> 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: 6305 bytes --]
next prev parent reply other threads:[~2014-06-16 21:02 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-14 12:00 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 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Peter Todd
2014-06-16 21:02 ` Daniel Rice [this message]
2014-06-16 20:32 ` [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 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=CAFDyEXghQ0yOpsoj2T4535m1XdKsdg6993hmp8iZQDy0ixRsQg@mail.gmail.com \
--to=drice@greenmangosystems$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=lawrence@greenaddress$(echo .)it \
--cc=mike@plan99$(echo .)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