From: Andy Schroder <info@AndySchroder•com>
To: Erik Aronesty <erik@q32•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Thomas Voegtlin <thomasv@electrum•org>
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
Date: Wed, 22 Jun 2016 11:12:04 -0400 [thread overview]
Message-ID: <576AAAC4.1020304@AndySchroder.com> (raw)
In-Reply-To: <CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 4098 bytes --]
>
> Only large merchants are able to maintain such an infrastructure;
> (even
> Coinbase recently failed at it, they forgot to update their
> certificate). For end users that is completely unpractical.
>
>
> Payment protocol is for when you buy stuff from purse.io
> <http://purse.io>, not really needed for face-to face transfers, end
> users, IMO.
I disagree with your statements. There are many face to face use cases
where the payment protocol is essential. Pretty much anything where the
payee's hardware device that the payer interacts with is automated in
public and/or operated or accessible by untrusted employees. In any of
those cases the software on the payee's hardware device can be modified.
Providing a signed payment request gives the payer additional confidence
that they are paying the correct person.
See some examples here: http://andyschroder.com/BitcoinFluidDispenser/2.3/
There was a secure bluetooth protocol that Andreas Schildbach and Eric
Voskuil and I were working on, but we never pulled it all the way
together. This would also need a two way exchange for a face to face
payment. This could be used without using some sort of key/certificate
verification service if being done between two humans who are the direct
senders and receivers of the payment and are using hardware that they
personally own (not necessarily the case of untrusted employees or
public vulnerable machines).
> The same benefit can be achieved without the complexity of BIP70, by
> extending the Bitcoin URI scheme. The requestor is authenticated using
> DNSSEC, and the payment request is signed using an EC private key. A
> domain name and an EC signature are short enough to fit in a
> Bitcoin URI
> and to be shared by QR code or SMS text.
>
> bitcoin:address?amount=xx&message=yyy&name=john.example.com
> <http://john.example.com>&sig=zzz
>
>
> I agree. A TXT record at that name could contain the pubkey.
Did you not see my previous message about the size of the bitcoin: URI
getting too big for NFC and QR codes? Do you not care about giving the
payer the option of using multiple destination payment addresses? This
is important for many reasons.
> That extension is sufficient to provide authenticated requests,
> without
> requiring a https server. The signed data can be serialized from the
> URI, and DNSSEC verification succeeds without requesting extra
> data from
> the requestor. The only assumption is that the verifier is able to
> make
> DNS requests.
>
>
> The problem is that there's no way for a merchant to /refuse /a
> payment without a direct communication with the merchant's server.
> Verify first / clear later is the rule. Check stock, ensure you can
> deliver, and clear the payment on the way out the door.
So, are you saying first the payer should send an unsigned transaction
for review, and then once the payee has agreed it's good, they can send
an ACK message back and then wait for the signed version? I don't think
this is a bad option to have. Many wallets simultaneously broadcast a
signed transaction to their peers and and also back to the payee via
https or bluetooth. So, you'd have to add another step to do the
unsigned transaction review in order to avoid a transaction being
accidentally broadcast that both parties don't like.
>
> Also, as a merchant processing monthly subscriptions, you don't want
> the first time you hear about a user's payment to be /after /it hits
> the blockchain. You could add a refund address to deal with it after
> the fact... stuff a refund address int OP_RETURN somehow?
>
> bitcoin:address?amount=xx¤cy=ccc&message=yyy&name=john.example.com
> <http://john.example.com>&offset=3d&interval=1m&sig=zzz
Again, my comments above about issues with using bitcoin: URI for
everything. Also, why do you want to bloat the blockchain with
unnecessary refund transaction data?
[-- Attachment #1.1.2: Type: text/html, Size: 7745 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2016-06-22 15:12 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 17:33 Erik Aronesty
2016-06-21 9:43 ` Andreas Schildbach
2016-06-21 17:09 ` Erik Aronesty
2016-06-21 19:50 ` Andy Schroder
2016-06-21 20:44 ` Luke Dashjr
2016-06-21 21:42 ` Erik Aronesty
2016-06-22 0:36 ` Luke Dashjr
2016-06-21 22:10 ` Peter Todd
2016-06-21 22:19 ` Peter Todd
2016-06-21 20:56 ` James MacWhyte
2016-06-21 21:17 ` Matt David
2016-06-21 22:13 ` Peter Todd
2016-06-21 22:50 ` James MacWhyte
2016-06-21 23:02 ` Peter Todd
2016-06-22 0:14 ` Justin Newton
2016-06-23 10:56 ` Peter Todd
2016-06-23 11:30 ` Pieter Wuille
2016-06-23 11:39 ` Peter Todd
2016-06-23 12:01 ` Pieter Wuille
2016-06-23 12:10 ` Peter Todd
2016-06-23 12:16 ` Pieter Wuille
2016-06-23 12:43 ` Peter Todd
2016-06-23 13:03 ` Erik Aronesty
2016-06-23 16:58 ` Aaron Voisine
2016-06-23 20:46 ` s7r
2016-06-23 21:07 ` Justin Newton
2016-06-23 21:31 ` Police Terror
2016-06-23 22:44 ` Justin Newton
2016-06-24 2:26 ` Erik Aronesty
2016-06-24 5:27 ` James MacWhyte
2016-06-22 7:57 ` Thomas Voegtlin
2016-06-22 14:25 ` Erik Aronesty
2016-06-22 15:12 ` Andy Schroder [this message]
2016-06-22 15:30 ` Erik Aronesty
2016-06-22 16:20 ` Andy Schroder
2016-06-22 17:07 ` Erik Aronesty
2016-06-22 20:11 ` James MacWhyte
2016-06-22 20:37 ` Erik Aronesty
2016-06-23 11:50 ` Andreas Schildbach
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=576AAAC4.1020304@AndySchroder.com \
--to=info@andyschroder$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=erik@q32$(echo .)com \
--cc=thomasv@electrum$(echo .)org \
/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