Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SJKZs-0004Lg-Ju for bitcoin-development@lists.sourceforge.net; Sun, 15 Apr 2012 08:12:56 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; envelope-from=gcbd-bitcoin-development@m.gmane.org; helo=plane.gmane.org; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1SJKZr-00012l-8O for bitcoin-development@lists.sourceforge.net; Sun, 15 Apr 2012 08:12:56 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SJKZi-0001bJ-SS for bitcoin-development@lists.sourceforge.net; Sun, 15 Apr 2012 10:12:46 +0200 Received: from g231204219.adsl.alicedsl.de ([92.231.204.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Apr 2012 10:12:46 +0200 Received: from andreas by g231204219.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Apr 2012 10:12:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Andreas Schildbach Date: Sun, 15 Apr 2012 10:12:37 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: g231204219.adsl.alicedsl.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 In-Reply-To: X-Spam-Score: -0.4 (/) 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 SPF_HELO_PASS SPF: HELO matches SPF record 1.1 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1SJKZr-00012l-8O Subject: Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 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: Sun, 15 Apr 2012 08:12:56 -0000 On 04/14/2012 10:20 PM, Jeff Garzik wrote: >>> Furthermore, many of these ideas -- like sending TX's directly to the >>> merchant -- involve far more direct payee<->payer communication on the >>> part of the wallet client than is currently envisioned >> >> Yes, though it's worth remembering that the original Bitcoin design >> did have participants communicate directly. When I talked with Satoshi >> in 2009 he saw the pay-to-IP-address mode imagined as the normal way >> to make payments, with pay-to-address being used as a kind of backup >> for when the recipient was offline. >> >> In the end that's not how things evolved, but it the pendulum could >> easily swing back the other way. > > IIRC pay-to-IP was removed because it was unreliable -and- detrimental > to privacy? ISTR Satoshi specifically disliking the privacy elements > of p2ip. > > But I also have a "gut feeling" that these sorts of payments and > direct communication should be done via a wholly separate protocol > than the bitcoin P2P protocol. Doing p2ip as it was done originally, > inside the bitcoin P2P protocol, was a mistake. Extensible as it is, > I think a better job -- and faster evolution -- can be done with a > separate protocol on a separate port. Just to let you know, Bitcoin Wallet for Android already supports directly sending transactions via NFC and QR-Code. Currently, receiving such a transaction is handled the same way as if it was received via P2P. This means the sender does not need to have internet access the moment he pays. The transaction is being broadcast into the P2P network by the receiver. Cheers, Andreas