Rebroadcast mechanism in Bitcoin P2P network

Hello World,

I had started working on this blog dedicated to Hal Finney in August: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019367.html

I have been able to track more than 10 Issues and Pull Requests from different Bitcoin projects that are focused on privacy. Wrote 3 blog posts and will write more often as I learn new things. There is a section called 'Hall of Fame' and 7 developers are listed in hof who worked on one or more pull requests that helped improve privacy in Bitcoin projects: Andrew Chow, chimp1984, jmacxx, Luke Dashjr, Samuel Dobson, Vasil Dimov and wpaulino.

Last post is about 'Rebroadcast mechanism' used in Bitcoin full node implementations: https://prayank23.github.io/camouflage//blog/rebroadcast/

Problem: Rebroadcast mechanism used in Bitcoin Core and Knots, rebroadcasts only our transactions. This helps spy nodes to link bitcoin addresses with IP addresses and also know that wallets are enabled for a node.

Solution by Amiti Uttarwar: New rebroadcast mechanism in which transactions are re-broadcasted based on fee rate and mempool age.

I have shared other details, my opinion and links to comments by Suhas Daftuar in the blog post since related pull request has been in draft mode for some time now.

Good Afternoon,

Thank-you for your good work cataloguing and writing about the contributions to Bitcoin.

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.

KING JAMES HRMH Great British Empire

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-10 07:13, Prayank via bitcoin-dev wrote:

> Hello World,
>
> I had started working on this blog dedicated to Hal Finney in August:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019367.html
>
> I have been able to track more than 10 Issues and Pull Requests from
> different Bitcoin projects that are focused on privacy. Wrote 3 blog
> posts and will write more often as I learn new things. There is a
> section called 'Hall of Fame' and 7 developers are listed in hof who
> worked on one or more pull requests that helped improve privacy in
> Bitcoin projects: Andrew Chow, chimp1984, jmacxx, Luke Dashjr, Samuel
> Dobson, Vasil Dimov and wpaulino.
>
> Last post is about 'Rebroadcast mechanism' used in Bitcoin full node
> implementations:
> https://prayank23.github.io/camouflage//blog/rebroadcast/
>
> Problem: Rebroadcast mechanism used in Bitcoin Core and Knots,
> rebroadcasts only our transactions. This helps spy nodes to link
> bitcoin addresses with IP addresses and also know that wallets are
> enabled for a node.
>
> Solution by Amiti Uttarwar: New rebroadcast mechanism in which
> transactions are re-broadcasted based on fee rate and mempool age.
>
> I have shared other details, my opinion and links to comments by Suhas
> Daftuar in the blog post since related pull request has been in draft
> mode for some time now.
>
> --
>
> Prayank
>
> A3B1 E430 2298 178F
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> 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,

Indeed, I reiterate that using the Tor network for Bitcoin or whatever protocol not related to the Tor Browser (ie browsing and HS) does not make sense, for plenty of reasons

But using the Tor protocol outside of the Tor network (and inside browsers for wallets for example) does: https://github.com/Ayms/node-Tor#presentation and https://github.com/Ayms/node-Tor#phase-4-and-phase-5, anonymizing nodes can just be already existing bitcoin nodes, example: https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853

Le 11/12/2021 à 17:21, Pieter Wuille via bitcoin-dev a écrit :

>> 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

On Sun, Dec 12, 2021, 7:42 AM Aymeric Vitte via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> Indeed, I reiterate that using the Tor network for Bitcoin or whatever
> protocol not related to the Tor Browser (ie browsing and HS) does not make
> sense, for plenty of reasons
>

Please cite this. It is very hard to believe.

Personally, I have encountered network blocking of bitcoin peers, and Tor is one way to reconnect with the network when this happens.

Regardless, reasonable rebroadcasting of nonlocal transactions is a hands-down good thing. This does not make them anonymous, but it does make it a little harder to track their origin, and additionally it makes their transmission more robust.

Every extra measure is a good thing, as everything eventually fails.

>

Using the Tor network to bypass censorship for bitcoin can work but is a very poor solution, the Tor network is very centralized, very small, watched and controlled, with plenty of features that do not apply to other protocols than those made to be used with the Tor Browser, Pieter gave a simple example, that you can solve easily changing the circuits, the problem remains that you really need to be a super expert to escape all the dangers of the Tor network, not even sure it's possible unless you use something else than the Tor project code

Believe it or not, node-Tor is a more than ten years old project (and not a duplicate of the Tor network), so I know what I am talking about, different studies of mine show also that the more you try to hide the more you can get caught, even on really decentralized networks like bittorrent, unlike another common belief that in such big networks it's difficult to track/deanonymize peers, it is not

Extra measures like rebroadcasting can maybe add something, but back to the previous sentence, extra measures can also help to catch/track you if not well designed/thought

What I am proposing since years, not only to bitcoin, is to use the Tor protocol independently of the Tor network, and from the browsers also acting as nodes (not to be misunderstood with the Tor Browser, this has nothing to do) probably someone one day will understand it

Le 12/12/2021 à 14:38, Karl a écrit :

>
>
> On Sun, Dec 12, 2021, 7:42 AM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     Indeed, I reiterate that using the Tor network for Bitcoin or
>     whatever protocol not related to the Tor Browser (ie browsing and
>     HS) does not make sense, for plenty of reasons
>
>
> Please cite this.  It is very hard to believe.
>
> Personally, I have encountered network blocking of bitcoin peers, and
> Tor is one way to reconnect with the network when this happens.
>
>
> Regardless, reasonable rebroadcasting of nonlocal transactions is a
> hands-down good thing.  This does not make them anonymous, but it does
> make it a little harder to track their origin, and additionally it
> makes their transmission more robust.
>
> Every extra measure is a good thing, as everything eventually fails.
>

On Sunday, December 12th, 2021 at 9:23 AM, Aymeric Vitte via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> Using the Tor network to bypass censorship for bitcoin can work but is a very poor solution, the Tor network is very centralized, very small, watched and controlled, with plenty of features that do not apply to other protocols than those made to be used with the Tor Browser, Pieter gave a simple example, that you can solve easily changing the circuits, the problem remains that you really need to be a super expert to escape all the dangers of the Tor network, not even sure it's possible unless you use something else than the Tor project code

FWIW, I wasn't talking about anything related to Tor's protocol or organization at all. What I meant is that because creating a hidden service has ~0 cost, it is trivial for anyone to spin up an arbitrary number of Bitcoin hidden services. Thus, if one runs a node that only connects to hidden services, it is fairly easily eclipsable.

It's just one example of a downside of (a particular way of) using Tor. That doesn't mean I recommend against using Tor for Bitcoin traffic at all; my point was simply that there are trade-offs, and aspects of privacy of the P2P protocol that Tor does not address, and thus one shouldn't assume that all problems are solved by "just use Tor".

Cheers,

Hi Aymeric,

> What I am proposing since years, not only to bitcoin, is to use the Tor

protocol independently of the Tor network, and from the browsers alsoacting as nodes (not to be misunderstood with the Tor Browser, this hasnothing to do) probably someone one day will understand it I understand the concept and like it. However had some issues with use of JavaScript and WebRTC which were partially answered in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019373.html

I like that you don't give up, passionate about privacy, nodes and contributing to Bitcoin. Not sure if you have commits in Bitcoin Core repository which is one of the weird requirements to get free tickets for open source stage of https://b.tc/conference/

I think presenting your idea with some demo, talking to other developers in community IRL would help your project. If you agree and interested to participate, please apply here: https://b.tc/conference/open-source

I have already requested few people and recommend you to share things about your project in conference. Let me know if you need sponsors for flight tickets as well.

Happy Weekend!

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

> It's just one example of a downside of (a particular way of) using
> Tor. That doesn't mean I recommend against using Tor for Bitcoin
> traffic at all; my point was simply that there are trade-offs, and
> aspects of privacy of the P2P protocol that Tor does not address, and
> thus one shouldn't assume that all problems are solved by "just use Tor".

There are many downsides since the default behavior of the Tor network does not apply to p2p networks, another example is a bitcoin node exiting transactions (I thought you were referring to this), since the same Tor circuit is used during some time most likely the transactions are related to the same node even if we don't know its IP

According to the bitcoin github example discussion link I gave, I am not saying that Tor network nodes should not be used, I am saying that they should be used à la node-Tor, or more precisely like the github example and http://www.peersm.com/Convergence-2020.pdf, one of the main differences are how behave the first node (ie the originating bitcoin node), HS/RDV, nb of hops, hybrid nodes

Another drawback is that bitcoin community lets bitcoin nodes operators play the way they like with torrc

@Prayank, regarding js/webrtc my previous answer was not partial, please email in private if you need more, it's just a part of the project (but important since disruptive), which is already advertised widely (bitcoin, ipfs, covid apps, videoconf, etc, there are plenty of links on github, lists, specs discussion, probably I should reference them), the answer is always the same: "very interesting, go ahead", but no, it is designed to be integrated by the projects, not by myself, and the only thing missing to get rid of myself is to release phase4