From: Erik Aronesty <erik@q32•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
Date: Mon, 20 Jun 2016 17:33:32 +0000 [thread overview]
Message-ID: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]
BIP 0070 has been a a moderate success, however, IMO:
- protocol buffers are inappropriate since ease of use and extensibility is
desired over the minor gains of efficiency in this protocol. Not too late
to support JSON messages as the standard going forward
- problematic reliance on merchant-supplied https (X509) as the sole form
of mechant identification. alternate schemes (dnssec/netki), pgp and
possibly keybase seem like good ideas. personally, i like keybase, since
there is no reliance on the existing domain-name system (you can sell with
a github id, for example)
- missing an optional client supplied identification
- lack of basic subscription support
*Proposed for subscriptions:*
- BIP0047 payment codes are recommended instead of wallet addresses when
establishing subscriptions. Or, merchants can specify replacement
addresses in ACK/NACK responses. UI confirms are *required *when there
are no replacement addresses or payment codes used.
- Wallets must confirm and store subscriptions, and are responsible for
initiating them at the specified interval.
- Intervals can *only *be from a preset list: weekly, biweekly, or 1,
2,3,4,6 or 12 months. Intervals missed by more than 3 days cause
suspension until the user re-verifies.
- Wallets *may *optionally ask the user whether they want to be notified
and confirm every interval - or not. Wallets that do not ask *must *notify
before initiating each payment. Interval confirmations should begin at *least
*1 day in advance of the next payment.
*Proposed in general:*
- JSON should be used instead of protocol buffers going forward. Easier to
use, explain extend.
- "Extendible" URI-like scheme to support multi-mode identity mechanisms on
both payment and subscription requests. Support for keybase://, netki://
and others as alternates to https://.
- Support for client as well as merchant multi-mode verification
- Ideally, the identity verification URI scheme is somewhat
orthogonal/independent of the payment request itself
Question:
Should this be a new BIP? I know netki's BIP75 is out there - but I think
it's too specific and too reliant on the domain name system.
Maybe an identity-protocol-agnostic BIP + solid implementation of a couple
major protocols without any mention of payment URI's ... just a way of
sending and receiving identity verified messages in general?
I would be happy to implement plugins for identity protocols, if anyone
thinks this is a good idea.
Does anyone think https:// or keybase, or PGP or netki all by themselves,
is enough - or is it always better to have an extensible protocol?
- Erik Aronesty
[-- Attachment #2: Type: text/html, Size: 3104 bytes --]
next reply other threads:[~2016-06-20 17:33 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 17:33 Erik Aronesty [this message]
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
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=CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com \
--to=erik@q32$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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