public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99•net>
To: Lawrence Nahum <lawrence@greenaddress•it>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
Date: Mon, 16 Jun 2014 17:43:26 +0200	[thread overview]
Message-ID: <CANEZrP0feDE52arsWyB_X40yd8ATCxfZaEV6RDYcG2rKm-Vapw@mail.gmail.com> (raw)
In-Reply-To: <loom.20140616T170619-497@post.gmane.org>

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

>
> I don't see more than a bunch of accepted payment methods anywhere I
> ever been in my life, I don't see merchants trusting more than a handful of
> third parties.
>

Sure. I buy this. Although the credit card market is a great example of
what we *don't* want: a stagnant duopoly of trusted third parties who
rampantly abuse their position. So I'd hope we see either (a) nobody really
caring about this BIP because Bitcoin gives good enough double spend
protection or (b) lots of anti-double-spend providers (hundreds seems fine).


> Ultimately you care because the alternative is to wait.
>

No, I will never wait. Neither me nor the merchant wants to me to be
pointlessly hanging around for an hour. The alternative is to pay by credit
card or cash. Outside of experiments there is no such thing as a shop that
only accepts only Bitcoin and will require me to wait for a block because I
didn't use a TTP to guarantee anti-double spends.

So this seems like a fundamental problem to me: having the ability to say,
"here is a proof I won't double spend" is fine, but it doesn't achieve
anything if the merchant would have sold me the goods in return for a
normal Bitcoin tx anyway, which in practice they always will because this
system starts out from zero users and would have to work upwards. I
*especially* will never use this system if I have to pay for it - I'd much
rather just put my money into a wallet that can't generate these proofs and
pay the sticker price.

Maybe what this BIP needs is an extra field that lets the merchant say, I
will give you a discount of X satoshis if you give me a no-double-spends
proof. In other words invert it: the sticker price is what normal Bitcoin
transactions cost, and then your wallet shows you the regular BIP70 price
minus the discount plus the third parties fee as what you finally pay. I
compare it to the sticker price the merchant is asking and if it's lower
I'm happy, and if it's higher my wallet would automatically avoid using the
TTP because I don't want to ever pay more, only less.

The market would then figure out if the fees the TTP charges are worth the
lower losses due to double spending fraud.

[-- Attachment #2: Type: text/html, Size: 2744 bytes --]

  reply	other threads:[~2014-06-16 15:43 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                         ` [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 [this message]
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=CANEZrP0feDE52arsWyB_X40yd8ATCxfZaEV6RDYcG2rKm-Vapw@mail.gmail.com \
    --to=mike@plan99$(echo .)net \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=lawrence@greenaddress$(echo .)it \
    /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