{"type":"rich","version":"1.0","author_name":"npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","author_url":"https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-06-21\n📝 Original message:\u003e keybase spam\n\ngood point about keybase spam, but i think it's limited to once hash per\nhour (?), not really too bad... the tx's are just root signatures, so you\ncan verify a whole keybase tree (up to the last hour) with very minimal\nbitcoin blockchain impact.\n\n\u003e What do you mean by \"replacement addresses\" and \"UI confirms\" here?\n\n\"Replacement addresses\" would take the place of BIP 32/47 support, if\nsomeone thought maybe that was too difficult to deal with.   So each time i\npaid Alice, Alice could generate a new payment address for the next monthly\npayment.   If you support BIP 32 pub seed, then there's no need for this.\nI don't know any wallets that support a BIP 32 pub seed (and then what,\nsome random number generator?) as a destination address yet.\n\n\u003e Disagree with hard-coding intervals, or mandating specific policies from\nthe\nservice providers.\n\nI think mandating is a harsh word here, but i I'm a strong believer in\nproviding strict guidelines that if people break, others can call them\non.   Giving someone a 12.3 +/- 5 day interval for payments using this\nprotocol would suck.   You should use payment channels for that stuff.\nThe idea is a lightweight protocol for getting monthly subscriptions\nworking.\n\n\n\n\nOn Tue, Jun 21, 2016 at 4:44 PM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote:\n\u003e \u003e BIP 0070 has been a a moderate success, however, IMO:\n\u003e \u003e\n\u003e \u003e - protocol buffers are inappropriate since ease of use and extensibility\n\u003e is\n\u003e \u003e desired over the minor gains of efficiency in this protocol.  Not too\n\u003e late\n\u003e \u003e to support JSON messages as the standard going forward\n\u003e\n\u003e IMO JSON is too prone to gratuitous inefficiency (both at network and CPU\n\u003e level), parser bugs, etc. Even the best C implementation (jansson) has\n\u003e serious\n\u003e issues with Number handling.\n\u003e\n\u003e A few years ago, I looked into binary alternatives to JSON and concluded\n\u003e they\n\u003e all had problems, while it seems more than reasonable to do even dynamic\n\u003e parsing of protobuf messages. So to conclude, I prefer to stick to protobuf\n\u003e unless a clearly superior protocol turns up.\n\u003e\n\u003e \u003e - problematic reliance on merchant-supplied https (X509) as the sole form\n\u003e \u003e of mechant identification.   alternate schemes (dnssec/netki), pgp and\n\u003e \u003e possibly keybase seem like good ideas.   personally, i like keybase,\n\u003e since\n\u003e \u003e there is no reliance on the existing domain-name system (you can sell\n\u003e with\n\u003e \u003e a github id, for example)\n\u003e\n\u003e X509 is entrenched, so it should remain supported. PGP might make sense for\n\u003e people already using it (it provides no real security for un-WoT-networked\n\u003e users), but unforunately, few people use it. Correct me if I'm wrong, but\n\u003e IIRC\n\u003e Keybase uses blockchain spam, so definitely not something to be encouraged\n\u003e if\n\u003e so. Namecoin seems like a more than reasonable decentralised solution, but\n\u003e will probably take some real work to implement (not that this is avoidable\n\u003e for\n\u003e a general-usage decentralised solution).\n\u003e\n\u003e \u003e - missing an optional client supplied identification\n\u003e\n\u003e What do you mean by this? There's the memo field at least.\n\u003e\n\u003e \u003e - lack of basic subscription support\n\u003e \u003e\n\u003e \u003e *Proposed for subscriptions:*\n\u003e \u003e\n\u003e \u003e - BIP0047 payment codes are recommended instead of wallet addresses when\n\u003e \u003e establishing subscriptions.  Or, merchants can specify replacement\n\u003e \u003e addresses in ACK/NACK responses.   UI confirms are *required *when there\n\u003e \u003e are no replacement addresses or payment codes used.\n\u003e\n\u003e I'd discourage anything using BIP 47 due to its serious design flaws.\n\u003e No reason a regular BIP 32 pub seed can't be used instead.\n\u003e\n\u003e What do you mean by \"replacement addresses\" and \"UI confirms\" here?\n\u003e\n\u003e \u003e - Wallets must confirm and store subscriptions, and are responsible for\n\u003e \u003e initiating them at the specified interval.\n\u003e \u003e\n\u003e \u003e - Intervals can *only *be from a preset list: weekly, biweekly, or 1,\n\u003e \u003e 2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause\n\u003e \u003e suspension until the user re-verifies.\n\u003e\n\u003e Disagree with hard-coding intervals, or mandating specific policies from\n\u003e the\n\u003e service providers.\n\u003e\n\u003e \u003e - Wallets *may *optionally ask the user whether they want to be notified\n\u003e \u003e and confirm every interval - or not.   Wallets that do not ask *must\n\u003e \u003e *notify before initiating each payment.   Interval confirmations should\n\u003e \u003e begin at *least *1 day in advance of the next payment.\n\u003e\n\u003e This is wallet policy, but maybe makes sense as a \"best practices\" BIP.\n\u003e\n\u003e \u003e *Proposed in general:*\n\u003e \u003e - JSON should be used instead of protocol buffers going forward.  Easier\n\u003e to\n\u003e \u003e use, explain extend.\n\u003e \u003e\n\u003e \u003e - \"Extendible\" URI-like scheme to support multi-mode identity mechanisms\n\u003e on\n\u003e \u003e both payment and subscription requests.   Support for keybase://,\n\u003e netki://\n\u003e \u003e and others as alternates to https://.\n\u003e \u003e\n\u003e \u003e - Support for client as well as merchant multi-mode verification\n\u003e \u003e\n\u003e \u003e - Ideally, the identity verification URI scheme is somewhat\n\u003e \u003e orthogonal/independent of the payment request itself\n\u003e \u003e\n\u003e \u003e Question:\n\u003e \u003e\n\u003e \u003e Should this be a new BIP?  I know netki's BIP75 is out there - but I\n\u003e think\n\u003e \u003e it's too specific and too reliant on the domain name system.\n\u003e \u003e\n\u003e \u003e Maybe an identity-protocol-agnostic BIP + solid implementation of a\n\u003e couple\n\u003e \u003e major protocols without any mention of payment URI's ... just a way of\n\u003e \u003e sending and receiving identity verified messages in general?\n\u003e \u003e\n\u003e \u003e I would be happy to implement plugins for identity protocols, if anyone\n\u003e \u003e thinks this is a good idea.\n\u003e \u003e\n\u003e \u003e Does anyone think https:// or keybase, or PGP or netki all by\n\u003e themselves,\n\u003e \u003e is enough - or is it always better to have an extensible protocol?\n\u003e \u003e\n\u003e \u003e - Erik Aronesty\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/9920f0c4/attachment.html\u003e"}