public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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


  parent reply	other threads:[~2021-12-12 22:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10 15:13 [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network 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 message]
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=a249de6ad8bbd739612e4b177459c626@willtech.com.au \
    --to=damian@willtech.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=bitcoin-dev@wuille.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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