From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YL94D-0006F5-5l for bitcoin-development@lists.sourceforge.net; Tue, 10 Feb 2015 11:33:21 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.182 as permitted sender) client-ip=209.85.216.182; envelope-from=martin.habovstiak@gmail.com; helo=mail-qc0-f182.google.com; Received: from mail-qc0-f182.google.com ([209.85.216.182]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YL94B-0000KA-95 for bitcoin-development@lists.sourceforge.net; Tue, 10 Feb 2015 11:33:21 +0000 Received: by mail-qc0-f182.google.com with SMTP id x3so12127031qcv.13 for ; Tue, 10 Feb 2015 03:33:13 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.224.55.71 with SMTP id t7mr51922414qag.53.1423567993289; Tue, 10 Feb 2015 03:33:13 -0800 (PST) Received: by 10.140.19.18 with HTTP; Tue, 10 Feb 2015 03:33:13 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Feb 2015 12:33:13 +0100 Message-ID: From: =?UTF-8?B?TeKStnJ0aW4gSOKStmJv4pOLxaF0aWFr?= To: Natanael Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (martin.habovstiak[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YL94B-0000KA-95 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 11:33:21 -0000 2015-02-10 12:19 GMT+01:00 Natanael : > > Den 10 feb 2015 12:08 skrev "Mike Hearn" : >> >> We can certainly imagine many BIP70 extensions, but for things like >> auto-filling shipping addresses, is the wallet the best place to do it? My >> browser already knows how to fill out this data in credit card forms, it >> would make sense to reuse that for Bitcoin. >> >> It sounds like you want a kind of Star-Trek negotiation agent thing, where >> your computer knows how to seek out the best deal because all the metadata >> is standardised. Such a thing would be an interesting project, but it's >> probably not best done in BIP70 given how it's deployed and used today. >> Rather, I'd suggest looking at the various HTML5 data standards which would >> allow merchants to advertise things like where they ship to in a machine >> readable and crawlable form. > > BIP70 doesn't have to be the place, but not needing to make sure the device > in question have that information stored already would be an improvement. > What protocol is used doesn't matter much, I just thought reusing BIP70 > would simplify implementation. In what universe is that simple? Your solution: browser extension + wallet + comminucation API + all the wallets need to implement it Our solution: just browser extension. If you hate writing browser extensions in Javascript, you can say it directly. ;) > > HTML5 elements could definitely be supported, through adding a tag in the > HTML form that says "prompt the Bitcoin wallet about the following payment > details". Just no. > > As one example, your browser could ask your hardware wallet over BLE for > this data. This way you barely have to trust the computer you're using at > all, as everything it does is confirmed on the hardware wallet before > payment (assuming it has a screen, which it should). Linking your hardware > wallet over BLE to new devices which you then use for browsing and shopping > could be trivial and yet allow secure auto-fill of this kind. This looks more interesting but is information about your location really so secret that you need to hold it in HW wallet? Because if so, you probably don't want to use untrusted machine anyway. (Or just use Qubes OS.) > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >