From: Lawrence Nahum <lawrence@greenaddress.it>
To: 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:05:27 +0000 (UTC) [thread overview]
Message-ID: <loom.20140616T185724-622@post.gmane.org> (raw)
In-Reply-To: CANEZrP0feDE52arsWyB_X40yd8ATCxfZaEV6RDYcG2rKm-Vapw@mail.gmail.com
Mike Hearn <mike <at> plan99.net> writes:
> 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).
Maybe hundreds, maybe less. I can imagine there would/could be local ones.
It's not the same as credit cards though: it's an open protocol with
explicit intent from all parties and no forced fees for normal transactions
- just for instant ones.
> 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.
I tend to agree but _today_ people are trying to use bitcoin and are waiting
and waiting ..
> 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.
This is a cultural thing. In some places if you pay by cards you pay extra.
I think it may be good to support both models but I like better the
transparent one even if I'm going to admit that the least transparent one
may be more attractive as it fools consumers.
> 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.
I think this is worth discussing further. Would love also more input from
other people on this.
next prev parent reply other threads:[~2014-06-16 17:05 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
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 [this message]
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=loom.20140616T185724-622@post.gmane.org \
--to=lawrence@greenaddress.it \
--cc=bitcoin-development@lists.sourceforge.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