From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 69FD0486 for ; Tue, 21 Jun 2016 21:42:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com [209.85.161.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3472C1A0 for ; Tue, 21 Jun 2016 21:42:41 +0000 (UTC) Received: by mail-yw0-f180.google.com with SMTP id l125so26149316ywb.2 for ; Tue, 21 Jun 2016 14:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7THyelUNXA0GNqwV1h/4sjifovXHrubEeeY7azUjPTI=; b=MkqMkUtGW4xrNWRSgD7oio+8SYPZ1xM3K29pxuF140kXfDvhx2mMZAiBw9djHESNS1 S3/8+L0CKAU7syYQ8GwSPuqAT2wz5+R26ejkimqqBVKBeCbkzr+da66BwFUy8ZmBy2cY QvjEvm3VLvWazN4SrPlkoLMc/+EQA4l8Bnn3kZHV5LIZlp9NeU3bsfMjup70+m73tMFv ITYAklPQTRC/024jmptSnAoRkTXzcJGUKXY0r/FhPMqSN9aSfpGVk75OGvtPdWlJEvZ+ mXMd4taAxaoBSyB1VPB9We+hi4mv3wv1lYJMquXDwX3BejKqYedgkqhOZgzDaB95ph/h V8VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7THyelUNXA0GNqwV1h/4sjifovXHrubEeeY7azUjPTI=; b=SaDXdl9wvC9L8+TCwvuzIAwu/xZ9LaP/Mul9bPzKcp/8T9N2moSja6OGEk9xkSYk2C ZlxciYBQEb5gtG2l6g+7UOjGEnuUGBhLs+5hErjdF5Y8riY8FSSEcDSR6mHQDE5iVCgq QZToNXixzPuwhYjFHuQTRzFNuD7BBZr//OW51TsN3BduPEYQWTKh2rAFkCkmTUEFRu1O nG/8sIn+84t7BtuIj0IY2Ae15LFNQQ2KYjy16N6HbVioTKVrGBGd4coLnrP1z6e0U7Nv 1eQ6avRhnuEYCUZ6hNrVXOx9CHzPxELV8o/cblOIQf4rv2IyCxD1kUCS0yvnia0yebPC TZZw== X-Gm-Message-State: ALyK8tJlh3zaUS/wj4L/qVJKYy6DyaycdR1LBgxtGQis+wcyWrrat2vSwqbqxsXYWHNMvVpCju3FsjJI9QB5Kw== X-Received: by 10.37.15.10 with SMTP id 10mr12315274ybp.51.1466545360357; Tue, 21 Jun 2016 14:42:40 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.37.72.68 with HTTP; Tue, 21 Jun 2016 14:42:39 -0700 (PDT) In-Reply-To: <201606212044.38931.luke@dashjr.org> References: <201606212044.38931.luke@dashjr.org> From: Erik Aronesty Date: Tue, 21 Jun 2016 17:42:39 -0400 X-Google-Sender-Auth: El1uJuvqfBt1VRrl_sOGnTdkUOg Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary=001a1138f4744050a00535d0b37d X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 21 Jun 2016 22:08:20 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 21:42:42 -0000 --001a1138f4744050a00535d0b37d Content-Type: text/plain; charset=UTF-8 > keybase spam good point about keybase spam, but i think it's limited to once hash per hour (?), not really too bad... the tx's are just root signatures, so you can verify a whole keybase tree (up to the last hour) with very minimal bitcoin blockchain impact. > What do you mean by "replacement addresses" and "UI confirms" here? "Replacement addresses" would take the place of BIP 32/47 support, if someone thought maybe that was too difficult to deal with. So each time i paid Alice, Alice could generate a new payment address for the next monthly payment. If you support BIP 32 pub seed, then there's no need for this. I don't know any wallets that support a BIP 32 pub seed (and then what, some random number generator?) as a destination address yet. > Disagree with hard-coding intervals, or mandating specific policies from the service providers. I think mandating is a harsh word here, but i I'm a strong believer in providing strict guidelines that if people break, others can call them on. Giving someone a 12.3 +/- 5 day interval for payments using this protocol would suck. You should use payment channels for that stuff. The idea is a lightweight protocol for getting monthly subscriptions working. On Tue, Jun 21, 2016 at 4:44 PM, Luke Dashjr wrote: > On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote: > > 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 > > IMO JSON is too prone to gratuitous inefficiency (both at network and CPU > level), parser bugs, etc. Even the best C implementation (jansson) has > serious > issues with Number handling. > > A few years ago, I looked into binary alternatives to JSON and concluded > they > all had problems, while it seems more than reasonable to do even dynamic > parsing of protobuf messages. So to conclude, I prefer to stick to protobuf > unless a clearly superior protocol turns up. > > > - 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) > > X509 is entrenched, so it should remain supported. PGP might make sense for > people already using it (it provides no real security for un-WoT-networked > users), but unforunately, few people use it. Correct me if I'm wrong, but > IIRC > Keybase uses blockchain spam, so definitely not something to be encouraged > if > so. Namecoin seems like a more than reasonable decentralised solution, but > will probably take some real work to implement (not that this is avoidable > for > a general-usage decentralised solution). > > > - missing an optional client supplied identification > > What do you mean by this? There's the memo field at least. > > > - 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. > > I'd discourage anything using BIP 47 due to its serious design flaws. > No reason a regular BIP 32 pub seed can't be used instead. > > What do you mean by "replacement addresses" and "UI confirms" here? > > > - 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. > > Disagree with hard-coding intervals, or mandating specific policies from > the > service providers. > > > - 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. > > This is wallet policy, but maybe makes sense as a "best practices" BIP. > > > *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 > --001a1138f4744050a00535d0b37d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> keybase spam

good point about keybas= e spam, but i think it's limited to once hash per hour (?), not really = too bad... the tx's are just root signatures, so you can verify a whole= keybase tree (up to the last hour) with very minimal bitcoin blockchain im= pact.=C2=A0=C2=A0

> What do you mean by "replacement addres= ses" and "UI confirms" here?

"Replacement = addresses" would take the place of BIP 32/47 support, if someone thoug= ht maybe that was too difficult to deal with.=C2=A0=C2=A0 So each time i pa= id Alice, Alice could generate a new payment address for the next monthly p= ayment.=C2=A0=C2=A0 If you support BIP 32 pub seed, then there's no nee= d for this.=C2=A0=C2=A0 I don't know any wallets that support a BIP 32 = pub seed (and then what, some random number generator?) as a destination ad= dress yet.

> Disagree with hard-coding intervals, or mandating sp= ecific policies from the
service providers.

I think mandating is a harsh word here, but= i I'm a strong believer in providing strict guidelines that if people = break, others can call them on.=C2=A0=C2=A0 Giving someone a 12.3 +/- 5 day= interval for payments using this protocol would suck.=C2=A0=C2=A0 You shou= ld use payment channels for that stuff.=C2=A0=C2=A0=C2=A0 The idea is a lig= htweight protocol for getting monthly subscriptions working.



On Tue, Jun 21, 2016 at 4:44 PM, Luke Dashjr <luke@da= shjr.org> wrote:
On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev = wrote:
> BIP 0070 has been a a moderate success, however, IMO:
>
> - protocol buffers are inappropriate since ease of use and extensibili= ty is
> desired over the minor gains of efficiency in this protocol.=C2=A0 Not= too late
> to support JSON messages as the standard going forward

IMO JSON is too prone to gratuitous inefficiency (both at network an= d CPU
level), parser bugs, etc. Even the best C implementation (jansson) has seri= ous
issues with Number handling.

A few years ago, I looked into binary alternatives to JSON and concluded th= ey
all had problems, while it seems more than reasonable to do even dynamic parsing of protobuf messages. So to conclude, I prefer to stick to protobuf=
unless a clearly superior protocol turns up.

> - problematic reliance on merchant-supplied https (X509) as the sole f= orm
> of mechant identification.=C2=A0 =C2=A0alternate schemes (dnssec/netki= ), pgp and
> possibly keybase seem like good ideas.=C2=A0 =C2=A0personally, i like = keybase, since
> there is no reliance on the existing domain-name system (you can sell = with
> a github id, for example)

X509 is entrenched, so it should remain supported. PGP might make se= nse for
people already using it (it provides no real security for un-WoT-networked<= br> users), but unforunately, few people use it. Correct me if I'm wrong, b= ut IIRC
Keybase uses blockchain spam, so definitely not something to be encouraged = if
so. Namecoin seems like a more than reasonable decentralised solution, but<= br> will probably take some real work to implement (not that this is avoidable = for
a general-usage decentralised solution).

> - missing an optional client supplied identification

What do you mean by this? There's the memo field at least.

> - lack of basic subscription support
>
> *Proposed for subscriptions:*
>
> - BIP0047 payment codes are recommended instead of wallet addresses wh= en
> establishing subscriptions.=C2=A0 Or, merchants can specify replacemen= t
> addresses in ACK/NACK responses.=C2=A0 =C2=A0UI confirms are *r= equired *when there
> are no replacement addresses or payment codes used.
I'd discourage anything using BIP 47 due to its serious design f= laws.
No reason a regular BIP 32 pub seed can't be used instead.

What do you mean by "replacement addresses" and "UI confirms= " here?

> - Wallets must confirm and store subscriptions, and are responsible fo= r
> 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.=C2=A0 =C2=A0Intervals missed by= more than 3 days cause
> suspension until the user re-verifies.

Disagree with hard-coding intervals, or mandating specific policies = from the
service providers.

> - Wallets *may *optionally ask the user whether they want to be notifi= ed
> and confirm every interval - or not.=C2=A0 =C2=A0Wallets that do not a= sk *must
> *notify before initiating each payment.=C2=A0 =C2=A0Interval confirmat= ions should
> begin at *least *1 day in advance of the next payment.

This is wallet policy, but maybe makes sense as a "best practices"= ; BIP.

> *Proposed in general:*
> - JSON should be used instead = of protocol buffers going forward.=C2=A0 Easier to
> use, explain extend.
>
> - "Extendible" URI-like scheme to support multi-mode identit= y mechanisms on
> both payment and subscription requests.=C2=A0 =C2=A0Support for keybas= e://, 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?=C2=A0 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 co= uple
> major protocols without any mention of payment URI's ... just a wa= y of
> sending and receiving identity verified messages in general?
>
> I would be happy to implement plugins for identity protocols, if anyon= e
> thinks this is a good idea.
>
> Does anyone think https:// or keybase, or PGP or netki all by themselv= es,
> is enough - or is it always better to have an extensible protocol?
>
> - Erik Aronesty

--001a1138f4744050a00535d0b37d--