* Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
@ 2021-12-12 18:49 Prayank
0 siblings, 0 replies; 10+ messages in thread
From: Prayank @ 2021-12-12 18:49 UTC (permalink / raw)
To: Aymeric Vitte; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]
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!
--
Prayank
A3B1 E430 2298 178F
[-- Attachment #2: Type: text/html, Size: 1728 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
@ 2021-12-10 15:13 Prayank
2021-12-11 3:49 ` damian
0 siblings, 1 reply; 10+ messages in thread
From: Prayank @ 2021-12-10 15:13 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1828 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
2021-12-10 15:13 Prayank
@ 2021-12-11 3:49 ` damian
2021-12-11 16:21 ` Pieter Wuille
0 siblings, 1 reply; 10+ messages in thread
From: damian @ 2021-12-11 3:49 UTC (permalink / raw)
To: Prayank, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
2021-12-11 3:49 ` damian
@ 2021-12-11 16:21 ` Pieter Wuille
2021-12-12 11:48 ` Aymeric Vitte
2021-12-12 22:32 ` damian
0 siblings, 2 replies; 10+ messages in thread
From: Pieter Wuille @ 2021-12-11 16:21 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
2021-12-11 16:21 ` Pieter Wuille
@ 2021-12-12 11:48 ` Aymeric Vitte
2021-12-12 13:38 ` Karl
2021-12-12 22:32 ` damian
1 sibling, 1 reply; 10+ messages in thread
From: Aymeric Vitte @ 2021-12-12 11:48 UTC (permalink / raw)
To: Pieter Wuille, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 5341 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
2021-12-12 11:48 ` Aymeric Vitte
@ 2021-12-12 13:38 ` Karl
2021-12-12 14:23 ` Aymeric Vitte
0 siblings, 1 reply; 10+ messages in thread
From: Karl @ 2021-12-12 13:38 UTC (permalink / raw)
To: Aymeric Vitte, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 794 bytes --]
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.
>
[-- Attachment #2: Type: text/html, Size: 1678 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
2021-12-12 13:38 ` Karl
@ 2021-12-12 14:23 ` Aymeric Vitte
2021-12-12 15:15 ` Pieter Wuille
0 siblings, 1 reply; 10+ messages in thread
From: Aymeric Vitte @ 2021-12-12 14:23 UTC (permalink / raw)
To: Karl, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]
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.
>
--
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
[-- Attachment #2: Type: text/html, Size: 5742 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
2021-12-12 14:23 ` Aymeric Vitte
@ 2021-12-12 15:15 ` Pieter Wuille
2021-12-13 12:40 ` Aymeric Vitte
0 siblings, 1 reply; 10+ messages in thread
From: Pieter Wuille @ 2021-12-12 15:15 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]
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,
--
Pieter
[-- Attachment #2: Type: text/html, Size: 1658 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
2021-12-12 15:15 ` Pieter Wuille
@ 2021-12-13 12:40 ` Aymeric Vitte
0 siblings, 0 replies; 10+ messages in thread
From: Aymeric Vitte @ 2021-12-13 12:40 UTC (permalink / raw)
To: Pieter Wuille, Bitcoin Protocol Discussion, Prayank
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
2021-12-11 16:21 ` Pieter Wuille
2021-12-12 11:48 ` Aymeric Vitte
@ 2021-12-12 22:32 ` damian
1 sibling, 0 replies; 10+ messages in thread
From: damian @ 2021-12-12 22:32 UTC (permalink / raw)
To: Pieter Wuille, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-12-13 13:17 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-12 18:49 [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network Prayank
-- strict thread matches above, loose matches on Subject: below --
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
2021-12-12 22:32 ` damian
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox