📅 Original date posted:2019-03-07
📝 Original message:Yes, I'm talking about P2P connections.
First and foremost, reject messages are an indication that the
transaction isn't going to confirm. Without these messages, we'd need to
revert to pre-BIP61 behaviour of using a timeout for reception of
network confirmations.
Regarding the content, these cases are useful to distinguish:
- Not enough fee
- UTXO already spent
- Tx validity/standardness (e.g. invalid signature)
While the last one in theority wouldn't be necessary if you produced
your software bug-free to begin with, this just isn't how software
development works. Developers need any indication they can get.
The first two happen even in the ideal case. Fees are impossible to
predict, and unintentional double spends happen because users clone
their wallet state.
On 07/03/2019 14.59, Sjors Provoost via bitcoin-dev wrote:
> Can you elaborate a bit on what kind of reject messages your users are getting? I assume the users wallet connects directly to the Bitcoin p2p network?
>
> What does the wallet do when a transaction is rejected? Does it forget about it (that seems unsafe) or compose another one (with overlapping inputs)?
>
> Sjors
>
>> Op 6 mrt. 2019, om 17:49 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>>
>> Reject messages cannot be replaced for debugging user problems. At least
>> unless you plan to make RPC or bitcoind logfiles available via the P2P
>> protocol (both probably not a good idea).
>>
>> The typical case is, I get mailed a wallet logfile with reject messages
>> and that's all I have. I cannot access the bitcoind logfile(s) of the
>> node(s) that generated the reject message in the first place. Nor can I
>> access their RPC interface.
>>
>> I strongly suggest re-enabling reject messages by default before 0.18.
>>
>>
>> On 06/03/2019 01.53, Marco Falke via bitcoin-dev wrote:
>>> Bitcoin Core may send "reject" messages as response to "tx", "block" or
>>> "version" messages from a network peer when the message could not be accepted.
>>>
>>> This feature is toggled by the `-enablebip61` command line option and has been
>>> disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
>>> time of writing). Nodes on the network can not generally be trusted to send
>>> valid ("reject") messages, so this should only ever be used when connected to a
>>> trusted node. At this time, I am not aware of any software that requires this
>>> feature, and I would like to remove if from Bitcoin Core to make the codebase
>>> slimmer, easier to understand and maintain. Let us know if your application
>>> relies on this feature and you can not use any of the recommended alternatives:
>>>
>>> * Testing or debugging of implementations of the Bitcoin P2P network protocol
>>> should be done by inspecting the log messages that are produced by a recent
>>> version of Bitcoin Core. Bitcoin Core logs debug messages
>>> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
>>> (`-debuglogfile=<debug.log>`).
>>>
>>> * Testing the validity of a block can be achieved by specific RPCs:
>>> - `submitblock`
>>> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
>>> potentially invalid POW
>>>
>>> * Testing the validity of a transaction can be achieved by specific RPCs:
>>> - `sendrawtransaction`
>>> - `testmempoolaccept`
>>>
>>> * Wallets should not use the absence of "reject" messages to indicate a
>>> transaction has propagated the network, nor should wallets use "reject"
>>> messages to set transaction fees. Wallets should rather use fee estimation
>>> to determine transaction fees and set replace-by-fee if desired. Thus, they
>>> could wait until the transaction has confirmed (taking into account the fee
>>> target they set (compare the RPC `estimatesmartfee`)) or listen for the
>>> transaction announcement by other network peers to check for propagation.
>>>
>>> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
>>> valid concerns about its removal.
>>>
>>> Marco
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 18:16:36
in reply to nevent1q…3zse
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Published at
2023-06-07 18:16:36Event JSON
{
"id": "cfa6bba3fb91ab2fff1f016aa8ba4a8b4499f6e514f33ed239ea55369eb05a68",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686161796,
"kind": 1,
"tags": [
[
"e",
"d23d84909ded4e86934b4199a32650fb490f51617593613544f6edda083d91e3",
"",
"root"
],
[
"e",
"46b7d46b345c7a3c3e95616e499e5e29417c6dfdb01cfa40633ecbbe0aa56a0a",
"",
"reply"
],
[
"p",
"e1ad0d0d83103f222425541294008149d215c1e1629b0bb37b98e19f698feb3e"
]
],
"content": "📅 Original date posted:2019-03-07\n📝 Original message:Yes, I'm talking about P2P connections.\n\nFirst and foremost, reject messages are an indication that the\ntransaction isn't going to confirm. Without these messages, we'd need to\nrevert to pre-BIP61 behaviour of using a timeout for reception of\nnetwork confirmations.\n\nRegarding the content, these cases are useful to distinguish:\n\n- Not enough fee\n- UTXO already spent\n- Tx validity/standardness (e.g. invalid signature)\n\nWhile the last one in theority wouldn't be necessary if you produced\nyour software bug-free to begin with, this just isn't how software\ndevelopment works. Developers need any indication they can get.\n\nThe first two happen even in the ideal case. Fees are impossible to\npredict, and unintentional double spends happen because users clone\ntheir wallet state.\n\n\nOn 07/03/2019 14.59, Sjors Provoost via bitcoin-dev wrote:\n\u003e Can you elaborate a bit on what kind of reject messages your users are getting? I assume the users wallet connects directly to the Bitcoin p2p network?\n\u003e \n\u003e What does the wallet do when a transaction is rejected? Does it forget about it (that seems unsafe) or compose another one (with overlapping inputs)?\n\u003e \n\u003e Sjors\n\u003e \n\u003e\u003e Op 6 mrt. 2019, om 17:49 heeft Andreas Schildbach via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e het volgende geschreven:\n\u003e\u003e\n\u003e\u003e Reject messages cannot be replaced for debugging user problems. At least\n\u003e\u003e unless you plan to make RPC or bitcoind logfiles available via the P2P\n\u003e\u003e protocol (both probably not a good idea).\n\u003e\u003e\n\u003e\u003e The typical case is, I get mailed a wallet logfile with reject messages\n\u003e\u003e and that's all I have. I cannot access the bitcoind logfile(s) of the\n\u003e\u003e node(s) that generated the reject message in the first place. Nor can I\n\u003e\u003e access their RPC interface.\n\u003e\u003e\n\u003e\u003e I strongly suggest re-enabling reject messages by default before 0.18.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On 06/03/2019 01.53, Marco Falke via bitcoin-dev wrote:\n\u003e\u003e\u003e Bitcoin Core may send \"reject\" messages as response to \"tx\", \"block\" or\n\u003e\u003e\u003e \"version\" messages from a network peer when the message could not be accepted.\n\u003e\u003e\u003e\n\u003e\u003e\u003e This feature is toggled by the `-enablebip61` command line option and has been\n\u003e\u003e\u003e disabled by default since Bitcoin Core version 0.18.0 (not yet released as of\n\u003e\u003e\u003e time of writing). Nodes on the network can not generally be trusted to send\n\u003e\u003e\u003e valid (\"reject\") messages, so this should only ever be used when connected to a\n\u003e\u003e\u003e trusted node. At this time, I am not aware of any software that requires this\n\u003e\u003e\u003e feature, and I would like to remove if from Bitcoin Core to make the codebase\n\u003e\u003e\u003e slimmer, easier to understand and maintain. Let us know if your application\n\u003e\u003e\u003e relies on this feature and you can not use any of the recommended alternatives:\n\u003e\u003e\u003e\n\u003e\u003e\u003e * Testing or debugging of implementations of the Bitcoin P2P network protocol\n\u003e\u003e\u003e should be done by inspecting the log messages that are produced by a recent\n\u003e\u003e\u003e version of Bitcoin Core. Bitcoin Core logs debug messages\n\u003e\u003e\u003e (`-debug=\u003ccategory\u003e`) to a stream (`-printtoconsole`) or to a file\n\u003e\u003e\u003e (`-debuglogfile=\u003cdebug.log\u003e`).\n\u003e\u003e\u003e\n\u003e\u003e\u003e * Testing the validity of a block can be achieved by specific RPCs:\n\u003e\u003e\u003e - `submitblock`\n\u003e\u003e\u003e - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with\n\u003e\u003e\u003e potentially invalid POW\n\u003e\u003e\u003e\n\u003e\u003e\u003e * Testing the validity of a transaction can be achieved by specific RPCs:\n\u003e\u003e\u003e - `sendrawtransaction`\n\u003e\u003e\u003e - `testmempoolaccept`\n\u003e\u003e\u003e\n\u003e\u003e\u003e * Wallets should not use the absence of \"reject\" messages to indicate a\n\u003e\u003e\u003e transaction has propagated the network, nor should wallets use \"reject\"\n\u003e\u003e\u003e messages to set transaction fees. Wallets should rather use fee estimation\n\u003e\u003e\u003e to determine transaction fees and set replace-by-fee if desired. Thus, they\n\u003e\u003e\u003e could wait until the transaction has confirmed (taking into account the fee\n\u003e\u003e\u003e target they set (compare the RPC `estimatesmartfee`)) or listen for the\n\u003e\u003e\u003e transaction announcement by other network peers to check for propagation.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I propose to remove \"reject\" messages from Bitcoin Core 0.19.0 unless there are\n\u003e\u003e\u003e valid concerns about its removal.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Marco\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "fc8ef7d4862f684490f2d383315d86747c4c8f24df7a900abed8b14701804b9116a70e9b281f0011f2ce7dbd7aaf09671246826946945c91842d659e9344f6ef"
}