rich1.0npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7https://nostr.ae/npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7njumphttps://nostr.ae📅 Original date posted:2019-03-13 📝 Original message:On 12/03/2019 23.14, Gregory Maxwell via bitcoin-dev wrote: > On Tue, Mar 12, 2019 at 7:45 PM Andreas Schildbach via bitcoin-dev > <bitcoin-dev at lists.linuxfoundation.org> wrote: >> 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 > > 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? It's implemented in bitcoinj's TransactionBroadcast class. Received reject messages are collected and -- if a certain consensus (currently: half of connected peers) is reached -- a RejectedTransactionException is raised. The handling of that exception in Bitcoin Wallet is extremely rudimentary. I think it still only shows the exception message. But certainly I was hoping to improve on this soon.