{"type":"rich","version":"1.0","author_name":"npub1pynqzktaxz4ffsv8w0ju86anmqmfjau252vwd43nmw0qdk3xrmtskld7pp","author_url":"https://nostr.ae/npub1pynqzktaxz4ffsv8w0ju86anmqmfjau252vwd43nmw0qdk3xrmtskld7pp","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-01-15\n📝 Original message:One variation of this, \"recycled address\", might avert misconceptions that\nthe \"re-use\" is exclusive to one's own identity.\n\n\nEric Martindale, relentless maker.\nhttp://www.ericmartindale.com\n+1 (919) 374-2020 | *BitMessage: *BM-2cWCmYBpV64FRSJpHHKWi1Cfc9W52jydwe\n*Note:* Beginning December 11th, 2013, I will only be intermittently\navailable via email, SMS, and BitMessage.  As a courtesy, please leave a\ndetailed message so that I can respond in kind.  Thanks!\n\n\nOn Wed, Jan 15, 2014 at 7:05 PM, Jeremy Spilman \u003cjeremy at taplink.co\u003e wrote:\n\n\u003e  Might I propose \"reusable address\".\n\u003e\n\u003e I think that describes it best to any non-programmer, and even more so\n\u003e encourages wallets to present options as 'one time use' vs 'reusable'.\n\u003e\n\u003e It definitely packs a marketing punch which could help drive adoption. The\n\u003e feature is only useful if/when broadly adopted.\n\u003e\n\u003e I think it meets all the criteria required:\n\u003e\n\u003e   - Communication between parties is a single message from the payee,\n\u003e which may be public\n\u003e   - Multiple payments to the same address are not publicly linkable on the\n\u003e blockchain\n\u003e   - The payee has explicitly designated they expect to receive more than\n\u003e one payment at that address\n\u003e   - Payer can publicly prove they made a payment to the reusable address\n\u003e by revealing a secret\n\u003e\n\u003e I have high hopes for this feature. The war *against* address reuse may\n\u003e soon be a distant memory.\n\u003e\n\u003e On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik \u003cjgarzik at bitpay.com\u003e\n\u003e wrote:\n\u003e\n\u003e \"static address\" seems like a reasonable attempt at describing intended\n\u003e use/direction.\n\u003e\n\u003e On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003ewrote:\n\u003e\n\u003e\u003e On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport \u003cbendavenport at gmail.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e \u003e But may I suggest we consider changing the name \"stealth address\" to\n\u003e\u003e \u003e something more neutral?\n\u003e\u003e\n\u003e\u003e ACK.  Regardless of the 'political' overtones, I think stealth is a\n\u003e\u003e little cringe-worthy.\n\u003e\u003e\n\u003e\u003e \"Private address\" would be fine if not for confusion with private-keys.\n\u003e\u003e\n\u003e\u003e \"Static address\" is perhaps the best in my view. (also helps improve\n\u003e\u003e  awareness that normal addresses are intended to be more one-use-ness)\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e CenturyLink Cloud: The Leader in Enterprise Cloud Services.\n\u003e Learn Why More Businesses Are Choosing CenturyLink Cloud For\n\u003e Critical Workloads, Development Environments \u0026 Everything In Between.\n\u003e Get a Quote or Start a Free Trial Today.\n\u003e\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=119420431\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140115/dad871e2/attachment.html\u003e"}