{"type":"rich","version":"1.0","author_name":"npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","author_url":"https://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-12-13\n🗒️ Summary of this message: Proposal for a way for merchants to translate a human-readable address into a bitcoin address, using HTTP(S) requests to a merchant-specified URL. Allows for per-transaction or fixed addresses.\n📝 Original message:I think the scope of this BIP is not so well defined right now. We need a\nway for merchants to translate a human readable, and more importantly\nhuman-writeable, address into a bitcoin address. I agree with Mike that a\nfixed address is not the way to go, because addresses should be used once\nfor a single transaction to be able to track payments.\n\nWhile firstbits sounds attractive at first, I think we can all agree that\nit just isn't feasible and would not allow per-transaction addresses. DNS\nsounds interesting for fixed addresses, but caching and propagation make it\ndifficult to use for per-transaction addresses that are to be generated\nad-hoc.\n\nHTTP(S) is the best option I think, merchants are probably using HTTP\nanyway for their shops. So something like\nhttp://merchant.com/btc/transaction/1234 sounds reasonable. But I think it\nshould not be over-engineered, it should be a simple HTTP(S) request to a\nmerchant specified URL that returns an ASCII document containing either a\nbitcoin: URI or simply the bitcoin address or even a 301 redirect. It's no\nuse to start defining URL schemes, it should be left to the merchants to\ndefine how to structure them.\n\nThis would allow a merchant to decide if he prefers per-transaction\naddresses, per-user transactions, fixed addresses or any combination.\n\nRegards,\ncdecker\n\n\nOn Tue, Dec 13, 2011 at 11:55 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\n\u003e I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the\n\u003e\u003e wall a picture of their QR code and a bitcoin address. I don't own a mobile\n\u003e\u003e phone so the QR code is\n\u003e\u003e useless.\n\u003e\n\u003e\n\u003e Fixed addresses like that are a temporary thing during Bitcoins maturation\n\u003e period. They lead to merchants exposing data they probably don't realize\n\u003e they're exposing, like their income, which is basically unacceptable for\n\u003e any payment system.\n\u003e\n\u003e There's no point trying to optimize a case where:\n\u003e\n\u003e 1) You are in the minority (no phone?)\n\u003e 2) The \"perfect experience\" leaks private data in such a way that would be\n\u003e deemed a gross security breach by any serious payment processor.\n\u003e\n\u003e OK, some thoughts on the general proposal, from the POV of what it'd take\n\u003e for a large deployment, like for every Gmail or every Facebook user. In\n\u003e terms of ease of implementation it is ordered HTTPS/HTTP then DNS trailing\n\u003e by a large margin. Big sites, even small sites, typically have high-speed\n\u003e load balancing and demuxing already implemented for HTTP[S] and it's\n\u003e usually easy to add new endpoints. The same is *not* true of DNS, and\n\u003e whilst coding up a custom DNS server is possible it's definitely a worse\n\u003e fit.\n\u003e\n\u003e FirstBits seems out of the question for the same privacy reasons as given\n\u003e above. No banking system worth its salt would let everyone look up other\n\u003e peoples income.\n\u003e\n\u003e The simplest approach would be to request a full public key with an HTTPS\n\u003e request like\n\u003e\n\u003e    foo at domain -\u003e\n\u003e https://domain/_bitcoin/getnewkey?user=foo\u0026label=Payment%20from%20Bob\n\u003e\n\u003e If you then want to turn the resulting public key into an address before\n\u003e creating a transaction you can obviously do that.\n\u003e\n\u003e BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is a\n\u003e big pile of source code. I think it's the same as above, but it's hard to\n\u003e tell without more effort.\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Systems Optimization Self Assessment\n\u003e Improve efficiency and utilization of IT resources. Drive out cost and\n\u003e improve service delivery. Take 5 minutes to use this Systems Optimization\n\u003e Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/\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/20111213/2f4582b5/attachment.html\u003e"}