damian at willtech.com.au [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-12 📝 Original message:Good Afternoon, You are ...
📅 Original date posted:2021-12-12
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev