path: root/40/cb211bbd4cce9d6a630a2934c487c88e4261ac

Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 69FD0486
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 21 Jun 2016 21:42:41 +0000 (UTC)
Received: by mail-yw0-f180.google.com with SMTP id l125so26149316ywb.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
	<201606212044.38931.luke@dashjr.org>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 21 Jun 2016 17:42:39 -0400
X-Google-Sender-Auth: El1uJuvqfBt1VRrl_sOGnTdkUOg
Message-ID: <CAJowKg+9kfOwvSH3GENr-=RYnctGHEw_7o-UmFqjAMJaaZ8AtA@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <luke@dashjr.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 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

<div dir=3D"ltr"><div><div>&gt; keybase spam<br><br>good point about keybas=
e spam, but i think it&#39;s limited to once hash per hour (?), not really =
too bad... the tx&#39;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 <br><br>&gt; What do you mean by &quot;replacement addres=
ses&quot; and &quot;UI confirms&quot; here?<br><br></div>&quot;Replacement =
addresses&quot; 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&#39;s no nee=
d for this.=C2=A0=C2=A0 I don&#39;t know any wallets that support a BIP 32 =
pub seed (and then what, some random number generator?) as a destination ad=
dress yet.<br><br>&gt; Disagree with hard-coding intervals, or mandating sp=
ecific policies from the<br>
service providers.<br><br></div>I think mandating is a harsh word here, but=
 i I&#39;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.<br><div><br><b=
r><div><div><br></div></div></div></div><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">On Tue, Jun 21, 2016 at 4:44 PM, Luke Dashjr <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@da=
shjr.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev =
wrote:<br>
&gt; BIP 0070 has been a a moderate success, however, IMO:<br>
&gt;<br>
&gt; - protocol buffers are inappropriate since ease of use and extensibili=
ty is<br>
&gt; desired over the minor gains of efficiency in this protocol.=C2=A0 Not=
 too late<br>
&gt; to support JSON messages as the standard going forward<br>
<br>
</span>IMO JSON is too prone to gratuitous inefficiency (both at network an=
d CPU<br>
level), parser bugs, etc. Even the best C implementation (jansson) has seri=
ous<br>
issues with Number handling.<br>
<br>
A few years ago, I looked into binary alternatives to JSON and concluded th=
ey<br>
all had problems, while it seems more than reasonable to do even dynamic<br=
>
parsing of protobuf messages. So to conclude, I prefer to stick to protobuf=
<br>
unless a clearly superior protocol turns up.<br>
<span class=3D""><br>
&gt; - problematic reliance on merchant-supplied https (X509) as the sole f=
orm<br>
&gt; of mechant identification.=C2=A0 =C2=A0alternate schemes (dnssec/netki=
), pgp and<br>
&gt; possibly keybase seem like good ideas.=C2=A0 =C2=A0personally, i like =
keybase, since<br>
&gt; there is no reliance on the existing domain-name system (you can sell =
with<br>
&gt; a github id, for example)<br>
<br>
</span>X509 is entrenched, so it should remain supported. PGP might make se=
nse for<br>
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&#39;m wrong, b=
ut IIRC<br>
Keybase uses blockchain spam, so definitely not something to be encouraged =
if<br>
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<br>
a general-usage decentralised solution).<br>
<span class=3D""><br>
&gt; - missing an optional client supplied identification<br>
<br>
</span>What do you mean by this? There&#39;s the memo field at least.<br>
<span class=3D""><br>
&gt; - lack of basic subscription support<br>
&gt;<br>
</span>&gt; *Proposed for subscriptions:*<br>
<span class=3D"">&gt;<br>
&gt; - BIP0047 payment codes are recommended instead of wallet addresses wh=
en<br>
&gt; establishing subscriptions.=C2=A0 Or, merchants can specify replacemen=
t<br>
</span>&gt; addresses in ACK/NACK responses.=C2=A0 =C2=A0UI confirms are *r=
equired *when there<br>
<span class=3D"">&gt; are no replacement addresses or payment codes used.<b=
r>
<br>
</span>I&#39;d discourage anything using BIP 47 due to its serious design f=
laws.<br>
No reason a regular BIP 32 pub seed can&#39;t be used instead.<br>
<br>
What do you mean by &quot;replacement addresses&quot; and &quot;UI confirms=
&quot; here?<br>
<span class=3D""><br>
&gt; - Wallets must confirm and store subscriptions, and are responsible fo=
r<br>
&gt; initiating them at the specified interval.<br>
&gt;<br>
</span>&gt; - Intervals can *only *be from a preset list: weekly, biweekly,=
 or 1,<br>
<span class=3D"">&gt; 2,3,4,6 or 12 months.=C2=A0 =C2=A0Intervals missed by=
 more than 3 days cause<br>
&gt; suspension until the user re-verifies.<br>
<br>
</span>Disagree with hard-coding intervals, or mandating specific policies =
from the<br>
service providers.<br>
<br>
&gt; - Wallets *may *optionally ask the user whether they want to be notifi=
ed<br>
&gt; and confirm every interval - or not.=C2=A0 =C2=A0Wallets that do not a=
sk *must<br>
&gt; *notify before initiating each payment.=C2=A0 =C2=A0Interval confirmat=
ions should<br>
&gt; begin at *least *1 day in advance of the next payment.<br>
<br>
This is wallet policy, but maybe makes sense as a &quot;best practices&quot=
; BIP.<br>
<br>
&gt; *Proposed in general:*<br>
<div class=3D"HOEnZb"><div class=3D"h5">&gt; - JSON should be used instead =
of protocol buffers going forward.=C2=A0 Easier to<br>
&gt; use, explain extend.<br>
&gt;<br>
&gt; - &quot;Extendible&quot; URI-like scheme to support multi-mode identit=
y mechanisms on<br>
&gt; both payment and subscription requests.=C2=A0 =C2=A0Support for keybas=
e://, netki://<br>
&gt; and others as alternates to https://.<br>
&gt;<br>
&gt; - Support for client as well as merchant multi-mode verification<br>
&gt;<br>
&gt; - Ideally, the identity verification URI scheme is somewhat<br>
&gt; orthogonal/independent of the payment request itself<br>
&gt;<br>
&gt; Question:<br>
&gt;<br>
&gt; Should this be a new BIP?=C2=A0 I know netki&#39;s BIP75 is out there =
- but I think<br>
&gt; it&#39;s too specific and too reliant on the domain name system.<br>
&gt;<br>
&gt; Maybe an identity-protocol-agnostic BIP + solid implementation of a co=
uple<br>
&gt; major protocols without any mention of payment URI&#39;s ... just a wa=
y of<br>
&gt; sending and receiving identity verified messages in general?<br>
&gt;<br>
&gt; I would be happy to implement plugins for identity protocols, if anyon=
e<br>
&gt; thinks this is a good idea.<br>
&gt;<br>
&gt; Does anyone think https:// or keybase, or PGP or netki all by themselv=
es,<br>
&gt; is enough - or is it always better to have an extensible protocol?<br>
&gt;<br>
&gt; - Erik Aronesty<br>
</div></div></blockquote></div><br></div>

--001a1138f4744050a00535d0b37d--