rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2019-03-07 📝 Original message:On Thu, Mar 7, 2019 at 11:46 PM Andreas Schildbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > 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. 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. > - Not enough fee Rejection on low fee (over the static minimum feerate) only happens at the point where the nodes mempool is full, which is already at a point where you might be waiting weeks for confirmation. 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. Output already spend is often completely indistinguishable from a missing parent and can't get rejects generated for it generally. 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).