rich1.0npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nhttps://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nnjumphttps://nostr.ae📅 Original date posted:2016-06-21 📝 Original message: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