From: Luke Dashjr <luke@dashjr.org>
To: Erik Aronesty <erik@q32.com>
Date: Wed, 22 Jun 2016 00:36:53 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.16; x86_64; ; )
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
	<201606212044.38931.luke@dashjr.org>
	<CAJowKg+9kfOwvSH3GENr-=RYnctGHEw_7o-UmFqjAMJaaZ8AtA@mail.gmail.com>
In-Reply-To: <CAJowKg+9kfOwvSH3GENr-=RYnctGHEw_7o-UmFqjAMJaaZ8AtA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201606220036.54258.luke@dashjr.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
Precedence: list

On Tuesday, June 21, 2016 9:42:39 PM Erik Aronesty wrote:
> > 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 suppose it makes sense that since every payment requires communication with 
the recipient, that the recipient could give you a new scriptPubKey each time. 
No need to save [potentially compromised] payment info in advance?

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

The point, as I see it, of payment protocol(s) is to deprecate addresses.
ie, this new protocol *could be* the BIP 32 pub seed destination address. ;)

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

Maybe just a field specifying how far in advance payments should be sent, 
then?

Luke