1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CABsx9T0o2BN+UyZt-TYcEXX_U0ztP3Rq3+arr_2C1MPEtU_dUg@mail.gmail.com>
References: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
<CAPg+sBhb3WOYnWRc020QbGwE0W4XeWWmXXTqYyAqrtB7h0+b8A@mail.gmail.com>
<CABsx9T0o2BN+UyZt-TYcEXX_U0ztP3Rq3+arr_2C1MPEtU_dUg@mail.gmail.com>
Date: Wed, 7 Aug 2013 23:17:41 +0200
X-Google-Sender-Auth: r_694M5pFWtl3jrb-OD_dnWBoQ8
Message-ID: <CANEZrP2+D4xu0t2efRPfg0t5gD8RRBk=KQEJH+0FF5J=vBmwiA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I'd like to hear from other wallet implementors. Do you have a notion<b=
r>
of 'locked inputs' ? =C2=A0The tricky bit in constructing a transac=
tion but<br>
not broadcasting it right away is the inputs must be locked, so<br>
they're not accidentally double-spent.<br></blockquote><div><br></div><=
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).</div>
<div><br></div></div></div></div>
--047d7b2e4c46699d6b04e36212b5--
|
