Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

From: damian@willtech•com.au
To: Pieter Wuille <bitcoin-dev@wuille•net>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
Date: Sun, 12 Dec 2021 14:32:21 -0800	[thread overview]
Message-ID: <a249de6ad8bbd739612e4b177459c626@willtech.com.au> (raw)
In-Reply-To: <dSBrti8VFr0lMNgTHw8pD-mAPLm0E4auJa234o0FNY67EUuEy1Dfb93INNIzoUb3j2dWSJjZtG7qncci1LhKAHOXzAzbEWOtXjnggr19J6w=@wuille.net>

Good Afternoon,

You are right, of course, I did nothing to differentiate between the 
privacy of the connection of the node, the identification of the public 
IP of the node, and the suspected original of a transaction.

If I understand, the reason for only the originating node to rebroadcast 
was because only that node can be authoritative,  but that logic is 
fallible once the transaction is signed - none of the nodes apart from 
the origin know about the transaction but they always manage to gossip.

Anyway, it is concept ACK from me and I know it has been a concern that 
I have raised previously, I presume some pseudo-random and lengthening 
per attempt length of time between receiving gossip about a transaction 
and rebroadcasting attempts. I have always worked with 
`mempoolexpiry=2160` and `maxmempool=900` and so far as I can presume 
mempool has never been full.

Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills

et al.

Willtech
www.willtech.com.au
www.go-overt.com
duigco.org DUIGCO API
and other projects

m. 0487135719
f. +61261470192

This email does not constitute a general advice. Please disregard this 
email if misdelivered.
On 2021-12-11 08:21, Pieter Wuille via bitcoin-dev wrote:
>> It is that the solution to privacy is to use privacy-enhancing network
>> communications, such as TOR. I am not against a mechanism to 
>> rebroadcast
>> transactions more robustly if the mempool of adjoining nodes has
>> forgotten about them, but the truth is, all transactions originate 
>> from
>> some node, and there are methods that allow an individual node to be
>> identified as the likely source of a transaction unless 
>> privacy-enabled
>> networks are utilised. Having a different method to cause rebroadcast
>> does not obfuscate the origin.
> 
> You're talking about distinct aspects of transaction privacy.
> 
> The rebroadcasting approach as it exists on the network, where wallets
> are responsible for their own rebroadcasting, directly reveals to your
> peers a relation between nodes and transactions: whenever any node
> relays the same transaction twice, it almost certainly implies they
> are the origin.
> 
> This is just a node-transaction relation, and not necessarily
> IP-transaction relation. The latter can indeed be avoided by only
> connecting over Tor, or using other privacy networks, but just hiding
> the relation with IP addresses isn't sufficient (and has its own
> downsides; e.g. Tor-only connectivity is far more susceptible to
> partition/Eclipse/DoS attacks). For example seeing the same node (even
> without knowing its IP) rebroadcast two transaction lets an observe
> infer a relation between those transactions, and that too is a privacy
> leak.
> 
> I believe moving to a model where mempools/nodes themselves are
> responsible for rebroadcasting is a great solution to improving this
> specific problem, simply because if everyone rebroadcasts, the
> original author doing it too does not stand out anymore. It isn't
> "fixing privacy", it's fixing a specific leak, one of many, but this
> isn't a black and white property.
> 
> Cheers,
> 
> --
> Pieter
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev