bitcoinj 0.15.7 release notes question

[Oscar Guindzberg]

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

--
Oscar Guindzberg

[Andreas Schildbach]

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.