From: Daniel Rice <drice@greenmangosystems•com>
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 01:53:38 -0700 [thread overview]
Message-ID: <CAFDyEXgbKtE4xrqMt3Ai9grD4otycVOEh95TtmvGCiQPv52-bg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]
Jumping in on this conversation because I've been doing research in this
area. Using a list of trusted providers in the payment details will be very
limiting and not scalable. I understand the reason for wanting the
supports_instant field, but I think that's a bad idea because the list
could literally be a million providers. Secondly, some merchants already
support instant transactions without any trust signature, so they should
also be able to advertise that as well.
I also don't believe that trusted or not trusted is a valid on and off
switch. For example, I might trust an instant provider for a 1 btc
transaction, but not 1,000,000 btc. Trust is all about the risk involved.
We can definitely learn from the current financial system in this realm.
I 100% agree with the In Payment Message portion of the BIP extension.
Here's how I think this will practically shake out in an automated way:
Anyone can become an instant provider, but nobody will trust them at first.
As that particular instant provider processes more and more transactions
without any double spends, they essentially build up trust. Based on the
past history of a particular instant provider a risk factor could be
calculated for a given transaction. This would also factor in the size of
the transaction. It would be very similar to a credit file showing the past
history of that particular instant provider based on all the transactions
they signed.
Andreas Schildbach <andreas <at> schildbach.de> writes:
> Just a quick comment:
>
> The supports_instant field seems redundant to me. First, as per your
> spec, you can derive it from trusted_instant_providers. And second, why
> do you need it at all? Protobuf is designed so it will simply ignore
> fields you don't know. So you can just send the instant_* fields in the
> Payment message without harm.
Agreed, supports_instant is redundant and can/should/will go.
trusted_instant_providers on the other hand I think is needed.
Sometimes the providers will charge fees for instant.
While the software can ignore the fields,
users may not want to pay for instant when the merchant may not accept it or
care (even if it would not break the protocol it would still be a waste of
fees)
Does it make sense?
Not all transactions from GreenAddress provide double spend protection, there
are additional checks on prevout that are normally not done when spending
normally, etc
[-- Attachment #2: Type: text/html, Size: 3030 bytes --]
next reply other threads:[~2014-06-16 9:15 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 8:53 Daniel Rice [this message]
-- strict thread matches above, loose matches on Subject: below --
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 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
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=CAFDyEXgbKtE4xrqMt3Ai9grD4otycVOEh95TtmvGCiQPv52-bg@mail.gmail.com \
--to=drice@greenmangosystems$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.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