rich1.0npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0njumphttps://nostr.ae📅 Original date posted:2016-06-21 📝 Original message:> 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/9920f0c4/attachment.html>