From: Aymeric Vitte <aymeric@peersm•com>
To: Pieter Wuille <bitcoin-dev@wuille•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Prayank <prayank@tutanota•de>
Subject: Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
Date: Mon, 13 Dec 2021 13:40:51 +0100 [thread overview]
Message-ID: <6341eec0-e6d8-fe15-4fde-b98d87b00c92@peersm.com> (raw)
In-Reply-To: <cd6J1hP7ryGspj5LgGk8uwSsh5FGoDwW9UCp4qHhbSn3MXgzMw1slbo8xwWv9kZxn95CcPPE5elPiOktz4-1drpiOgfi-TtGzr66cdS6AuI=@wuille.net>
> 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
next prev parent reply other threads:[~2021-12-13 13:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-10 15:13 Prayank
2021-12-11 3:49 ` damian
2021-12-11 16:21 ` Pieter Wuille
2021-12-12 11:48 ` Aymeric Vitte
2021-12-12 13:38 ` Karl
2021-12-12 14:23 ` Aymeric Vitte
2021-12-12 15:15 ` Pieter Wuille
2021-12-13 12:40 ` Aymeric Vitte [this message]
2021-12-12 22:32 ` damian
2021-12-12 18:49 Prayank
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6341eec0-e6d8-fe15-4fde-b98d87b00c92@peersm.com \
--to=aymeric@peersm$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@wuille$(echo .)net \
--cc=prayank@tutanota$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox