📅 Original date posted:2019-03-13
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190313/29d5abf3/attachment-0001.html>;
Dustin Dettmer [ARCHIVE] /
npub1x5…kqsqu
2023-06-07 18:16:37
in reply to nevent1q…d5nx
Author Public Key
npub1x54n25utwk7dzwzvk2v0aknptez5gxdwcyrxx2wgc0lnhgvwu72qmkqsquPublished at
2023-06-07 18:16:37Event JSON
{
"id": "32578645f0514f80115fa6892f7b8495eea4be6aa917dd590e40b8060907248d",
"pubkey": "352b35538b75bcd1384cb298feda615e454419aec1066329c8c3ff3ba18ee794",
"created_at": 1686161797,
"kind": 1,
"tags": [
[
"e",
"d23d84909ded4e86934b4199a32650fb490f51617593613544f6edda083d91e3",
"",
"root"
],
[
"e",
"80c9049bbb8bdff6086221f4e77e821eac9fcb137d9dfe2d1bc54d1361a10edd",
"",
"reply"
],
[
"p",
"69c195a4597fa65bbcc5d79bd7146eb5db2b986c7c12aaee95f8dd2984cc521e"
]
],
"content": "📅 Original date posted:2019-03-13\n📝 Original message:I’ve solved the same problem in a different way.\n\n1) Submit a transaction\n2) Collect all reject messages (that have matching txid in the reject data)\n3) Wait 16 seconds after first error message received (chosen semirandomly\nfrom trial and error) before processing errors\n4) Wait for our txid to be submitted back to us through the mempool, if we\nget it notify success and delete all pending error events\n5) Signal failure with the given reject code if present (after the 16\nseconds have elapsed)\n6) If no error or success after 20 seconds, signal timeout failure\n\nThis works fairly well in testing. Newer transaction types seem to generate\nreject codes 100% of the time (from at least one node when sending to 4\nnodes) so this culling / time delay approach is essentially required.\n\nOn a related note: One issue is that RBF attempts with too small a fee and\naccidental double spends (with enough fee for 1 tx but not a RBF) both\ngenerate the same reject code: not enough fee.\n\nA new reject code for RBF based too small of fee would definitely make for\na better user experience as I’ve seen this exact problem create confusion\nfor users.\n\nRemoving reject codes would make for a much worse user experience. “Your tx\nfailed and we have no idea why” would be the only message and it would\nrequire waiting for a full timeout.\n\nOn Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzberg via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e \u003e I'd like to better understand this, but it would be easier to just\n\u003e \u003e read the code than ask a bunch of questions. I tried looking for the\n\u003e \u003e handling of reject messages in Android Bitcoin Wallet and BitcoinJ\n\u003e \u003e and didn't really find and handling other than logging exceptions.\n\u003e \u003e Would you mind giving me a couple pointers to where in the code\n\u003e \u003e they're handled?\n\u003e\n\u003e\n\u003e https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190313/29d5abf3/attachment-0001.html\u003e",
"sig": "68804ef93db3f8ccd921e5a1efb1218cdff057c83a1823ffd49aa175d571e38aa589ff7026ee67c5b4fd67667f77ba7682bf5544d76177f1baaa8e4c1403a1d2"
}