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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
|
Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6DD7410C3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Mar 2019 09:46:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com
[209.85.128.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1D7AA852
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Mar 2019 09:46:31 +0000 (UTC)
Received: by mail-wm1-f42.google.com with SMTP id f3so2195497wmj.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Mar 2019 02:46:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date
:user-agent:mime-version:in-reply-to:content-language;
bh=b+ubiPNu5G+Ep9A8OVUYbOIHClR2MC0UM8iD12tBqd0=;
b=ovW9yRxyWhUhlRGesczBmQo8CAHFlbpPoDUOSflIjDWaX9aF1hOp0gjjI8y0fb9mO8
b6LPDo7/z/cdjBnAGT6Dpock1rs6jUavZB1QA8S6jORKe1zzxjf5BJmgeDL1vxS9/gZt
a6h9fM7xRk1R76j8QW0MwuivdxtV2eHfL6gEk7tUHUaDHMJJbyyzJ4UOq6t6L02/7brU
JFNP8ybhIn6nEwOIzVyPqYa/gr3mot5df0DKegCxF9hcWMarLcOy3JpRJFDmloPFM6HO
RQxr/ijBBx+EQZWaUYacj2bRWbZ4PAn6HSXJxlmcHdNDziNWS3gMVhkJpbfAtmwfi1Mk
E3yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt
:message-id:date:user-agent:mime-version:in-reply-to
:content-language;
bh=b+ubiPNu5G+Ep9A8OVUYbOIHClR2MC0UM8iD12tBqd0=;
b=bpiQJo0sx8CWgyoEgnVHvwyFApmNeeKT+9L7lIMxDVzTiFOJjU8+crrdcJWL1OpN7/
2hDuC5htnYmnpKxDuW4iDBkGtm6Xg7DYCGHOCESRbnc2zIobpljgM77I3UbWA85YHk5V
akc5wkbrJp4aBGcXcjRi3r/9lhG53Nb5wj077fKr2rKYO7ZBXV2Gvu/qLG2v0rp1d4+Y
e/zPIPJarG5hVh8oJ+KopWSvJX+rVrRCfo8rP362AVwJ5/B92qY9UdWShL4J0JBUL9VE
p9wVQtNkHyNIrUG08LmpT8SG/UoYNN9tr3sV2Dc1r/Qw6yyz62Qs4fvi7f1xmDra2dIQ
2w9w==
X-Gm-Message-State: APjAAAUq2C5XRwZYOne7pGuIaQ9rdTAcL3eDinfmACLtF3lOejAPHCxt
3hoB5qxunGRudIfQHRMtLjM=
X-Google-Smtp-Source: APXvYqzzCe5Xf5MOqsmDHRVv7NswrHdbW5zL1QUM6Fnyoqco7CTEPJAc8z1xZPLF41aRQcBLegWqgg==
X-Received: by 2002:a1c:9684:: with SMTP id y126mr1881165wmd.124.1552556789616;
Thu, 14 Mar 2019 02:46:29 -0700 (PDT)
Received: from ?IPv6:2a01:cb1d:44:6500:9d6d:71b2:cb71:cb17?
([2a01:cb1d:44:6500:9d6d:71b2:cb71:cb17])
by smtp.googlemail.com with ESMTPSA id
h13sm17461791wrt.89.2019.03.14.02.46.28
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 14 Mar 2019 02:46:29 -0700 (PDT)
To: Dustin Dettmer <dustinpaystaxes@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Oscar Guindzberg <oscar.guindzberg@gmail.com>
References: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
<q5otmg$4vh7$1@blaine.gmane.org>
<78CAF294-56E2-477C-B46F-C65A56357820@sprovoost.nl>
<q5rm39$87ck$1@blaine.gmane.org>
<CAAS2fgR5D_jo6eZp5Z09TzBg8ux8wP24=km_0O-XhLsJQPtVxw@mail.gmail.com>
<q68p34$1pc8$1@blaine.gmane.org>
<CAAS2fgS-+ucC2gfYGhEfKx0Upct45gcU2smTv_QVmb=NoU3sCw@mail.gmail.com>
<CAPoHUxMfKqxH4p9gsVzHD2S29nZaQfpW=oLgVs999v4GG83uXQ@mail.gmail.com>
<CABLeJxTq-KZz9K=3EgyD5sFpgNzJs_NdOLQdGv=VkGUeLcfteg@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Openpgp: preference=signencrypt
Autocrypt: addr=vitteaymeric@gmail.com; prefer-encrypt=mutual; keydata=
mQINBFdW8uABEAC7HJScbB2d/lmYoY5Cn9loEjJwfLs1LC3om030bWFGiH3Ceo5XeHUT94rw
Pi+HaHU8ea94425SXIFsnqp/ouoT/8Ffn6vED0OoRmK0jE4fqDApXSpoL2mHX9PAGdUItMtD
YrxBiBZNfMkctEsm4NrQ4TCvB3Yrm6Fc69inXJjUoYgPw5tHafEeI8Qwh0j99JZZDKcAqIra
JF3MPc59rATz0qOJtRP9EpsPVFwjJe13zN6CHILwiVgrL8EtT5WKCVO6ATxh60LHi8+MwPxV
V31zp/NNI5Hck+XocEMO98ZvUu9X8ZxmnOk/+9pBxXEwUqSGUNWdmPJLncpI23Usce3u/MOo
M2C4T4rD4J0XrXiyBvbeTvwq4qVNlyggeWzlBH+YpEYgDctPq4gNh4eoTtAkf8URtBeke5bQ
CGdaZt/jxv8nvmxs9V/iSyg5ldJLQktHStXOo0OZ7FEB2C6Ggtymm4hm2MHYg07Q1MGJrFLa
oJZkJ3JeXnVsZMam7ypQtld6rRa96CvH+llXwux6aQ5hKdzmBBMQ10LlkZhkExgTawbeqdiG
RMP2DjD5go6TPdAHS4NN34SBkrTWLqgWOjN/lnG77bbLnpMl0P+xBTuqw1oSXaDbcdHE2nGY
lRno/ZZIfr+1Bq56DZLBX/WpnAT4f5WtofL4CxQM9SbG6byyewARAQABtCJBeW1lcmljIFZp
dHRlIDxheW1lcmljQHBlZXJzbS5jb20+iQI/BBMBCAApBQJXVvLgAhsjBQkJZgGABwsJCAcD
AgEGFQgCCQoLBBYCAwECHgECF4AACgkQKh17NCYnrDm3WhAAlYmgtSmtfqjBvQMqkmtqiQJA
aZkzFZWt6+zroduHH5/Tp8jh73gFqCUyRrl/kcKvs2+XQhfrOwk1R6OScF25bpnrZSeuyJnZ
MZu4T0P2tGS8YdddQvWUHMtI9ZnQRuYmuZT23/hgj1JnukuGvGLeY0yDUa1xFffPN39shp5X
FPMcpIVOV3bs+xjAdsyfRyO3qJAD1FGiR7ggJeoaxUbKZ6NtcVUPPRMjVTKfopkuDwKY318m
BE0epfxSZ/iRhsJ0/sREUWgbgq4/QvCFwBKzgz7fTikGmf8OELWSdofmXs7gOtmMc3el8fJu
W8PVa/OsIQHDmwSzvxmE8ba5M8bdwOYEraTWFArIymAAtRXKxmuYpkqKfeSlbCwae3W+pgNT
8nKYRVAFlMtIxYkmPYyMTk9kCscmSqugGWbWdnqe/dhVaa31xa1qO1tDH24D2/tjCJRQt4Jk
AEWNSmjCmjfeArMEFTGlZwMTAjVXErLSPbLOsZiZhD9sjvSbfzrtJiMli2h9+Dvds+AJk1PM
O8LW7cCNyFoCk4OdAxzJHobZ25G+uy4NSQEHgxLC2iuh/tugz1tOHnQczPc/3AkVVI9A5DF1
gbVRBJh6rI7sAcwuR76uoOs0Rpp7r6I66xqU/5eq8g1OsJp89tw0ppSIa0YmaxNqQZ0l3rVX
o/ZwpBjtNQS5Ag0EV1by4AEQANhlz3Ywff4dY1HTdn05v0wVUxZzW2PUih+96m6EhpUrD9BT
vxriKtbgxm/zl+5YAlThbrk9f0QyVTHJ95Z1/M5qjuksP9Zn3qZ/8ylANDkN2s3z8Bq/LJA+
u7+APhMqyFWK0FqNCOogClvijiKPEzkU6tmDGO6wZ5pR/u8Fdq7DGQgwgyGZZc7qstte0M7l
yx7bVRlPBqvd6kyX3YubQHzkctf46nFjiYZgKawdWFsA3PCdSBupbhixL5d/t1UK9ZTiQJcf
0uhHzT06qwolFrm/ugkLDHtE4Zo3BuKch47Sms8P2hJ08gABxeJHg0ZgkIUy/Xf4nHbDCBJw
T8tE8pWYWA2ECiPNo0TOCMVOueEzISUNKINfCuFHSbMQU39hgt3ofxODbAjOiO3e/iu1ptck
AkuVBdtjOBP4tHRGxVrbf5EuAV5U5xtiSxMwMgojg0GIXZjnT/8uvWqcLqtJILRMmmu+WNvD
oxuiJzcTJhDai9oujmxQwcpMvgrBB89KSTDyitO5XVjZqaR7Zxvvn3rM4bAms/lotv9+pTyh
spazTIxb80u0ifJ6y1RxAkxQCfWwps1i3VbsM6OKX78aUyOf5V4ihXF57M37tOqPRwFvz6a+
AIIhUNMTLo2H+o6Vw9qbX8SUxPHPs6YpJ8lWQJ9OMWHE+SbaDFAi/D5hYRubABEBAAGJAiUE
GAEIAA8FAldW8uACGwwFCQlmAYAACgkQKh17NCYnrDmk4Q/9Fuu0h5HvIiO3ieYA2StdE7hO
vv2THuesjJDsj6aQUTgknaxKptJogNe3dDyIT+FHxXmCw0Nrbm9Q3ryl80z/G9utfFNO3Gwc
q31QW3n3LJHnpqdrV3WsRzT5NwJMVtiIAGRrX8ZomtarWHT0PeEHC2xBdFzRrJtmkrwer0Wc
0nBzD7vk1XEXC9nODbmlgsesoHFgRwQBst3wClCbX1gv8aSfxQNpaf9UBC8DmyrQ621UXpBo
PvcFEtWxV44vJfP0WOLCCN0Pzv2F2I66iKo7VMqbr5jlNAXJN9I1hXb7qwYJmBC9j5oeEoqv
A9d44WWpxrdAr8qih4Nv89k9+9F6NoqORY3FGuVDKiW8CVhCmGT7bIvNeyicVBZFipXqPcKL
VFduO2c5Ubc2npMWLUF1k9JJc9tH75l3+F/0RbYVTzGAZ+zSaudwR6h8YiCN2DBZGZkJEZbh
3X/l6jtijMN/W9sPHyyKvm/TmeEC27S3TqZPZ8PUQLxZC70V6gMbenh01JdSQsn5t8Ru0RNh
Blt0g7IyZyIKCE9b+TyzbYpX6qgqEBUHia5b0vyPtQacWQlZ8uqnghAqNkLluEsy7Q/7xG6M
wXUYEDsFOmB9dKOzcAOIhpxlVjSKu5mzXJ11sEtE8nyF5NJ/riCA7FGcjlki3zIpzQUNo9v7
vXl2h6Tivlk=
Message-ID: <0305189e-1a8c-68f3-e3ce-74b9cb15ce1e@gmail.com>
Date: Thu, 14 Mar 2019 10:46:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:60.0) Gecko/20100101
Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <CABLeJxTq-KZz9K=3EgyD5sFpgNzJs_NdOLQdGv=VkGUeLcfteg@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------C31129F0AFF2DB064881A604"
Content-Language: fr
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 14 Mar 2019 10:36:11 +0000
Cc: Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [bitcoin-dev] Removal of reject network messages from Bitcoin
Core (BIP61)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 09:46:32 -0000
This is a multi-part message in MIME format.
--------------C31129F0AFF2DB064881A604
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Apparently I don't have the same experience than others here, what I
encountered is no reject message received for wrong txs, but from what I
understand here it's not unusual to receive reject message for valid
txs, then I don't see how it can be really helpful/relied, given also
that the reject messages are unclear and even can be misleading
As it was written already I found it useful only for debugging purposes,
at least it can give some kind of ideas about what happened,
bitcoin-transactions is implementing the bitcoin protocol but does not
act as a node and does not pretend to fake a node behavior waiting for
example to get the tx back, is the method of sending a getdata for a
given tx to see if it was accepted by a node wrong ? It can't guarantee
100% that it was successful and will propagate but I see that you are
doing completely different things
Le 13/03/2019 à 23:30, Dustin Dettmer via bitcoin-dev a écrit :
> I’ve solved the same problem in a different way.
>
> 1) Submit a transaction
> 2) Collect all reject messages (that have matching txid in the reject
> data)
> 3) Wait 16 seconds after first error message received (chosen
> semirandomly from trial and error) before processing errors
> 4) Wait for our txid to be submitted back to us through the mempool,
> if we get it notify success and delete all pending error events
> 5) Signal failure with the given reject code if present (after the 16
> seconds have elapsed)
> 6) If no error or success after 20 seconds, signal timeout failure
>
> This works fairly well in testing. Newer transaction types seem to
> generate reject codes 100% of the time (from at least one node when
> sending to 4 nodes) so this culling / time delay approach is
> essentially required.
>
> On a related note: One issue is that RBF attempts with too small a fee
> and accidental double spends (with enough fee for 1 tx but not a RBF)
> both generate the same reject code: not enough fee.
>
> A new reject code for RBF based too small of fee would definitely make
> for a better user experience as I’ve seen this exact problem create
> confusion for users.
>
> Removing reject codes would make for a much worse user experience.
> “Your tx failed and we have no idea why” would be the only message and
> it would require waiting for a full timeout.
>
> On Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzberg via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> > I'd like to better understand this, but it would be easier to just
> > read the code than ask a bunch of questions. I tried looking for the
> > handling of reject messages in Android Bitcoin Wallet and BitcoinJ
> > and didn't really find and handling other than logging exceptions.
> > Would you mind giving me a couple pointers to where in the code
> > they're handled?
>
> https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
--------------C31129F0AFF2DB064881A604
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Apparently I don't have the same experience than others here,
what I encountered is no reject message received for wrong txs,
but from what I understand here it's not unusual to receive reject
message for valid txs, then I don't see how it can be really
helpful/relied, given also that the reject messages are unclear
and even can be misleading</p>
<p>As it was written already I found it useful only for debugging
purposes, at least it can give some kind of ideas about what
happened, bitcoin-transactions is implementing the bitcoin
protocol but does not act as a node and does not pretend to fake a
node behavior waiting for example to get the tx back, is the
method of sending a getdata for a given tx to see if it was
accepted by a node wrong ? It can't guarantee 100% that it was
successful and will propagate but I see that you are doing
completely different things</p>
<div class="moz-cite-prefix">Le 13/03/2019 à 23:30, Dustin Dettmer
via bitcoin-dev a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CABLeJxTq-KZz9K=3EgyD5sFpgNzJs_NdOLQdGv=VkGUeLcfteg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>
<div dir="auto">I’ve solved the same problem in a different way.</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">1) Submit a transaction</div>
<div dir="auto">2) Collect all reject messages (that have matching
txid in the reject data)</div>
<div dir="auto">3) Wait 16 seconds after first error message
received (chosen semirandomly from trial and error) before
processing errors</div>
<div dir="auto">4) Wait for our txid to be submitted back to us
through the mempool, if we get it notify success and delete all
pending error events</div>
<div dir="auto">5) Signal failure with the given reject code if
present (after the 16 seconds have elapsed)</div>
<div dir="auto">6) If no error or success after 20 seconds, signal
timeout failure</div>
<div dir="auto"><br>
</div>
<div dir="auto">This works fairly well in testing. Newer
transaction types seem to generate reject codes 100% of the time
(from at least one node when sending to 4 nodes) so this culling
/ time delay approach is essentially required.</div>
<div dir="auto"><br>
</div>
<div dir="auto">On a related note: One issue is that RBF attempts
with too small a fee and accidental double spends (with enough
fee for 1 tx but not a RBF) both generate the same reject code:
not enough fee.</div>
<div dir="auto"><br>
</div>
<div dir="auto">A new reject code for RBF based too small of fee
would definitely make for a better user experience as I’ve seen
this exact problem create confusion for users.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Removing reject codes would make for a much worse
user experience. “Your tx failed and we have no idea why” would
be the only message and it would require waiting for a full
timeout.</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2019 at 3:16
PM Oscar Guindzberg via bitcoin-dev <<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">> I'd
like to better understand this, but it would be easier to
just<br>
> read the code than ask a bunch of questions. I tried
looking for the<br>
> handling of reject messages in Android Bitcoin Wallet
and BitcoinJ<br>
> and didn't really find and handling other than logging
exceptions.<br>
> Would you mind giving me a couple pointers to where in
the code<br>
> they're handled?<br>
<br>
<a
href="https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Move your coins by yourself (browser version): <a class="moz-txt-link-freetext" href="https://peersm.com/wallet">https://peersm.com/wallet</a>
Bitcoin transactions made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-transactions">https://github.com/Ayms/bitcoin-transactions</a>
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre>
</body>
</html>
--------------C31129F0AFF2DB064881A604--
|
