I was referring to the bloom filter recalculations. It's done asynchronously in bitcoinj and I suspect race conditions. (I've seen missed transactions after transactions sent by users. I suspect the issues were not visible before SegWit since non-SegWit doesn't really require recalculations.)
By dropping the peer and reconnecting it forces an immediate filter calculation which is done synchronously in the connecting process afair. That is of course just a work around. A real fix would get rid of the COutPoint matching and would always match the "previous output script" (the script being spent), which would greatly reduce code complexity and fix a good amount of privacy issues with server-side filtering. But it would need changes to BIP37 and Bitcoin Core. The main reason for peer dropping is improved privacy. Also, it improves the measurement of broadcast confirmations since you likely will hear your transaction back on the freshly connected peer. You're welcome to not use the peer dropping – it should then behave as before. On 24/09/2020 20.49, Oscar Guindzberg wrote: > Hi, > I found this on bitcoinj 0.15.7 release notes: > > "When a transaction is broadcast, peers being broadcasted to are > disconnected afterwards. Others will take their place. This improves > privacy and avoids rarely tested code paths." > > What code paths are referred to? > > I am evaluating disabling this feature in my bitcoinj fork. If several > txs are broadcasted in a short period of time, I see a risk of > dropping too many peers and then have problems broadcasting txs. > > Thanks > -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoinj/3f882fdd-cb8b-f638-27d0-80eb9701b63d%40schildbach.de.
