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
Cc: Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [bitcoin-dev] Removal of reject network messages from Bitcoin
 Core (BIP61)
Precedence: list

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 &lt;<a
              href="mailto:bitcoin-dev@lists.linuxfoundation.org"
              moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>&gt;
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; I'd
            like to better understand this, but it would be easier to
            just<br>
            &gt; read the code than ask a bunch of questions. I tried
            looking for the<br>
            &gt; handling of reject messages in Android  Bitcoin Wallet
            and BitcoinJ<br>
            &gt; and didn't really find and handling other than logging
            exceptions.<br>
            &gt; Would you mind giving me a couple pointers to where in
            the code<br>
            &gt; 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--