📅 Original date posted:2019-03-12
📝 Original message:(Posting again, since my previous reply didn't appear)
On 08/03/2019 01.52, Gregory Maxwell via bitcoin-dev wrote:
> That is already required because even in the presence of perfectly
> honest and cooperative hosts reject messages at most can only tell you
> about first-hop behaviour. It won't even tell you if the transaction
> was ever even attempted to be sent to a next hop. So alternative
> handling must be provided and must be reliable for the software to
> work at all regardless of reject messages.
>
> Rejection causes were also not stable or reliable because the validity
> criteria cannot generally be tested independently. For example, if a
> transaction is queued due to missing a parent it isn't rejected
> because missing the parent is often a temporary issue, but its feerate
> cannot be measured without the parent. Later, when the parent is
> obtained, the transaction can then be rejected due to feerate-- but no
> reject is sent then.
These two cases are understood and handled by current code. Generally
the idea is take reject messages serious, but don't overrate the lack
of. Luckily, network confirmations fill the gap. (Yes, a timeout is
still useful. But at least it almost never happens.)
> Similarly, the error state detected for things like invalid signatures
> are often not very useful. The software knows that script execution
> returned false, but in the general case _why_ it returned false is not
> clear, and a straightforward high performance validation
> implementation doesn't necessarily yield a good way of figuring out
> and propagating up that information. (I think invalid signatures end
> up returning a stack-nonempty state from validation currently, as an
> example of that).
Nevertheless, it has been proven as useful in debugging (just recently
when I implemented the witness signature hash in bitcoinj). I think
Wilmer Paulino summed up this point quite nicely in his reply to this
thread.
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 18:16:36
in reply to nevent1q…ukgw
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Published at
2023-06-07 18:16:36Event JSON
{
"id": "1cb56f7b4dcb026c0c622ffe22c2c11c56f5a34245bcc4b08cba840f2fd5bb74",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686161796,
"kind": 1,
"tags": [
[
"e",
"d23d84909ded4e86934b4199a32650fb490f51617593613544f6edda083d91e3",
"",
"root"
],
[
"e",
"2ccb19c59550e584a53715624f84e1379bb115b732b61fd708331904548ab9c6",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2019-03-12\n📝 Original message:(Posting again, since my previous reply didn't appear)\n\n\nOn 08/03/2019 01.52, Gregory Maxwell via bitcoin-dev wrote:\n\n\u003e That is already required because even in the presence of perfectly\n\u003e honest and cooperative hosts reject messages at most can only tell you\n\u003e about first-hop behaviour. It won't even tell you if the transaction\n\u003e was ever even attempted to be sent to a next hop. So alternative\n\u003e handling must be provided and must be reliable for the software to\n\u003e work at all regardless of reject messages.\n\u003e\n\u003e Rejection causes were also not stable or reliable because the validity\n\u003e criteria cannot generally be tested independently. For example, if a\n\u003e transaction is queued due to missing a parent it isn't rejected\n\u003e because missing the parent is often a temporary issue, but its feerate\n\u003e cannot be measured without the parent. Later, when the parent is\n\u003e obtained, the transaction can then be rejected due to feerate-- but no\n\u003e reject is sent then.\n\nThese two cases are understood and handled by current code. Generally\nthe idea is take reject messages serious, but don't overrate the lack\nof. Luckily, network confirmations fill the gap. (Yes, a timeout is\nstill useful. But at least it almost never happens.)\n\n\u003e Similarly, the error state detected for things like invalid signatures\n\u003e are often not very useful. The software knows that script execution\n\u003e returned false, but in the general case _why_ it returned false is not\n\u003e clear, and a straightforward high performance validation\n\u003e implementation doesn't necessarily yield a good way of figuring out\n\u003e and propagating up that information. (I think invalid signatures end\n\u003e up returning a stack-nonempty state from validation currently, as an\n\u003e example of that).\n\nNevertheless, it has been proven as useful in debugging (just recently\nwhen I implemented the witness signature hash in bitcoinj). I think\nWilmer Paulino summed up this point quite nicely in his reply to this\nthread.",
"sig": "776714fa751618f1b94ed9a51f4b7dedb187e9fef4ac3affed8681e3ca7c45b585913550468d852c3b1d23b9a73f55653ecf5122847f1489988ff7a6ec061612"
}