Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7B77-00061E-1e for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:17:49 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.46 as permitted sender) client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f46.google.com; Received: from mail-oa0-f46.google.com ([209.85.219.46]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V7B75-0006Ay-Da for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:17:49 +0000 Received: by mail-oa0-f46.google.com with SMTP id l10so4308100oag.33 for ; Wed, 07 Aug 2013 14:17:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.140.168 with SMTP id rh8mr2054108oeb.76.1375910262050; Wed, 07 Aug 2013 14:17:42 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.84.231 with HTTP; Wed, 7 Aug 2013 14:17:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Aug 2013 23:17:41 +0200 X-Google-Sender-Auth: r_694M5pFWtl3jrb-OD_dnWBoQ8 Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: multipart/alternative; boundary=047d7b2e4c46699d6b04e36212b5 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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 X-Headers-End: 1V7B75-0006Ay-Da Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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: Wed, 07 Aug 2013 21:17:49 -0000 --047d7b2e4c46699d6b04e36212b5 Content-Type: text/plain; charset=UTF-8 > I'd like to hear from other wallet implementors. Do you have a notion > of 'locked inputs' ? The tricky bit in constructing a transaction but > not broadcasting it right away is the inputs must be locked, so > they're not accidentally double-spent. > bitcoinj separates the concept of committing a tx to the wallet from broadcasting it. However by default transactions that weren't seen in the chain yet will be announced when a new peer is connected to. It'd take extra code to suppress that, and it's unclear to me why that's useful. I agree with Pieter that it should be the merchants responsibility to get the tx out there, but having the client do the broadcast as well can't really hurt (except perhaps some privacy impact). --047d7b2e4c46699d6b04e36212b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
I'd like to hear from other wallet implementors. Do you have a notion of 'locked inputs' ? =C2=A0The tricky bit in constructing a transac= tion but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.

<= div>bitcoinj separates the concept of committing a tx to the wallet from br= oadcasting it. However by default transactions that weren't seen in the= chain yet will be announced when a new peer is connected to. It'd take= extra code to suppress that, and it's unclear to me why that's use= ful. I agree with Pieter that it should be the merchants responsibility to = get the tx out there, but having the client do the broadcast as well can= 9;t really hurt (except perhaps some privacy impact).

--047d7b2e4c46699d6b04e36212b5--