Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CAB4BB2F for ; Wed, 13 Mar 2019 22:30:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26BB9D3 for ; Wed, 13 Mar 2019 22:30:58 +0000 (UTC) Received: by mail-wr1-f43.google.com with SMTP id y15so3750139wro.4 for ; Wed, 13 Mar 2019 15:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=67/7mqZOVBsOtZA7S/0Nx9xWrRkJD17DGXflbxn/yk0=; b=LJgoZjjToiHp1czD61/KonCjoza3FyQcJAWOXUjK5QA/suc7maGNg4yKKchPKA/oRJ 7TQlp6WGbJ9VrriqMqRFjL2dkCxj8GCwzyYzfsQmZUatwK7m0ZvBFLPHVOPsWDVd/ZjZ SkBgw2qdDTzaIDgyvdZqi4jy9Go+4sSDuMzUEw4ZhengeIQ1RFnbxT2HjYOI9tuZa08W LqDkB1hO5t+x5vGoNU5PE6tW9QJ9PuK123irspb1eZNmXEZ6PDxn1AcnHwcXPp0ebehr EHvkD0uiTJBQFZri18Z3W0E5d38OyEZ9dA5GsSRf9BAA4r+Rrv1vEy3iYzGB58S4jneX uf1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=67/7mqZOVBsOtZA7S/0Nx9xWrRkJD17DGXflbxn/yk0=; b=gXEAF6de31NmJseAJ5/cxtzOZbuo47gzNarC6cqZyZkhm6Zim3Ha9AFaxu4eug7t5f 44QPqqoun2ZkmSeWEnPJmGkuijFOAm642f6y5V3QzBursOe/vIJJlQGwBoRepehSrSrD u670Uo1KIN7wLW4KGqKyBNypS1D9hLmoj+0TrEyxBCfLkkc58S7e0p4jlqi7Z7KpqS4M r7Mwnj3f29T7NTIU4SZSaAGJZ6oprItlkifvZ5pRK/Be97v8f20OtHNgDH7RnsCppulc zSc309+tfC/Xub+xcXS+ns7DagEyTpIUEIl1pgTLkeU1PI2WRX4ocj8Zm/JcQpJyFHzw G8DA== X-Gm-Message-State: APjAAAVm4/XVuOCdeulcA6OeI6GhU4Kg54TfaRwXN2TSx3Af/Ju8rcgG T/wO3wrwByRK0ql3swY9S39w3JuLQjuaS4enuSMx9A== X-Google-Smtp-Source: APXvYqz6nbL2NNWxo5kn0PGg/tYgbgfL3B9YhRK5kBgea+ZdLiEikzSvcdsj6fJe9+xFMNQIrXbim8RKK86Gcwauu3A= X-Received: by 2002:a5d:4f02:: with SMTP id c2mr24437995wru.30.1552516256314; Wed, 13 Mar 2019 15:30:56 -0700 (PDT) MIME-Version: 1.0 References: <78CAF294-56E2-477C-B46F-C65A56357820@sprovoost.nl> In-Reply-To: From: Dustin Dettmer Date: Wed, 13 Mar 2019 15:30:44 -0700 Message-ID: To: Bitcoin Protocol Discussion , Oscar Guindzberg Content-Type: multipart/alternative; boundary="000000000000f73ace0584015b48" 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: Wed, 13 Mar 2019 22:38:14 +0000 Cc: Andreas Schildbach 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 22:30:58 -0000 --000000000000f73ace0584015b48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99ve 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=E2=80=99ve seen this exact problem create con= fusion for users. Removing reject codes would make for a much worse user experience. =E2=80= =9CYour tx failed and we have no idea why=E2=80=9D would be the only message and it wo= uld 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> 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/b= itcoinj/core/TransactionBroadcast.java#L93-L108 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000f73ace0584015b48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99ve solved the same problem in a different = way.

1) Submit a t= ransaction
2) Collect all reject messages (that have= matching txid in the reject data)
3) Wait 16 second= s after first error message received (chosen semirandomly from trial and er= ror) before processing errors
4) Wait for our txid t= o be submitted back to us through the mempool, if we get it notify success = and delete all pending error events
5) Signal failur= e 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 wor= ks 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 expe= rience as I=E2=80=99ve seen this exact problem create confusion for users.<= /div>

Removing reject codes wo= uld make for a much worse user experience. =E2=80=9CYour tx failed and we h= ave no idea why=E2=80=9D would be the only message and it would require wai= ting for a full timeout.

On Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzb= erg via bitcoin-dev <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=C2=A0 Bitcoin Wallet and Bitcoi= nJ
> 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/s= rc/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000f73ace0584015b48--