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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
