public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

From: Erik Aronesty <erik@q32•com>
To: Thomas Voegtlin <thomasv@electrum•org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
Date: Wed, 22 Jun 2016 10:25:03 -0400	[thread overview]
Message-ID: <CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmail.com> (raw)
In-Reply-To: <576A44F1.9050108@electrum.org>

[-- Attachment #1: Type: text/plain, Size: 2567 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, not really needed
for face-to face transfers, end users, IMO.


> 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&sig=zzz
>

I agree.  A TXT record at that name could contain the pubkey.


> 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.

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&currency=ccc&message=yyy&name=john.example.com
&offset=3d&interval=1m&sig=zzz

... But what if the merchant simply goes out of business.  No OP_RETURN
will help you here.   You'll be posting transactions into a dead wallet.
You could have some way of posting a "ping" transaction, and then
monitoring for a valid response.   But this is "spamming the blockchain for
communications".

No, I think BIP075 is fine.   You just need to extend the *PaymentAck *with
a single field, instead of just having a memo.

next_payment_days : integer

The wallet, when it sees this field, re-initiates an invoice request after
the selected number of days, after presenting the user with the content of
the memo field which will presumably explain the subscription.   Wallet
vendors can let users "auto approve" vendors as needed.

This is, I think, the absolute minimum needed to update BIP0070/0075 for
subscriptions.

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

next prev parent reply	other threads:[~2016-06-22 14:25 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 [this message]
2016-06-22 15:12     ` Andy Schroder
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=CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmail.com \
    --to=erik@q32$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=thomasv@electrum$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox