From: Aymeric Vitte <vitteaymeric@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Gleb Naumenko <naumenko.gs@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
Date: Fri, 5 Jun 2020 17:41:48 +0200 [thread overview]
Message-ID: <03508424-639f-2f3f-8b0e-5b1013f5269a@gmail.com> (raw)
In-Reply-To: <AHiqSOkmCAgH6Lo_yUd93T0cJ9PDzz9pVxctgZ_08j9BjkyQR5my57uaPrYmiRJEWpmlij69ILg5YW0XB0oOmEpoE9Ta5YTffsULRXBUa6k=@protonmail.com>
Hi,
As far as I understand your answer is "let's try to use what exists",
this is not what I am proposing and not the Tor network, no "standard"
exit nodes, different hidden services, decentralized anonymizer network
unlike the Tor network, nodes are anonymizing themselves
Comments below, please let me know what is unclear in the description of
the project so I can modify it because all the time I get the impression
that it is mixed with the Tor network while it just has a very little to
do with it, and I don't get that the simple principle of communicating
between nodes using the Tor protocol without RDV points is never considered
Regards,
Le 05/06/2020 à 13:44, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>> The issue each time there are discussions/research linking to Tor is that it is biased since the beginning because based on a wrong postulate: using the Tor network
>>
> Well, in the interest of using the wrong tool for a highly important job, let me present this thought:
Then for an important job people should use the right tool...
>
> * The Tor network is weakened due to its dependence on a limited set of exit nodes.
And centralized structure, limited set of nodes to make it short, for
some (or a lot) misbehaving, not designed for bitcoin, nothing prevents
bitcoin from operating its own anonymizer system, which I am proposing
> * "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services.
Good to a certain extent... if you want to hide that you are operating a
bitcoin node you can use RDV points (ie hidden services) but if you
don't care you just connect anonymized circuits between bitcoin nodes,
this is more "direct" and does not exist in the Tor network, this
includes light clients that can act as relays also
> * Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet connections, the issue is with Tor-to-clearnet connections.
There are plenty of Tor-to-Tor issues, not theoretical but in the real
world, "Tor-to-clearnet" can be done outside of the Tor network, ie the
bitcoin network
> * Of course, no miner is going to run over Tor because latency, so all the miners will be on clearnet.
Probably, again I am not proposing a remake of the Tor network, I don't
see the use for a miner to hide (neither for a bitcoin node to use RDV
points), but they can be part of the global anonymized system, please
see below
> * So make your own bridge between Tor and clearnet.
> * Run two fullnodes on your computer (with sufficient ingenuity, you can probably share their block storages, or make one pruning).
> * One fullnode is on the public network but runs in `blocksonly` so it does not propagate any transactions (which might be attached to your public IP).
> * The other fullnode is on the Tor network and has an `-addnode` to the public-network node via `localhost`, which I assume is very hard for an eclipse attacker to get at.
> * Use the Tor-fullnode to propagate your transactions.
Yes but one full node should be able to do this alone, ie implement both
interfaces, like miners and everybody in fact (or Peersm bridges with
bittorrent if you look at the history of the project)
>
> Of course, the eclipse attacker can still attack all Tor exit nodes and block outgoing transaction traffic to perform eclipse attacks.
> And if you decide to propagate transactions to the public-network node then you pretty much lose your privacy there.
Please see the convergence link, it's not based on the assumption that
"the more you are the better you can hide and the lesser you can get
attacked", this does not work at all, it's based on the assumption that
even with a reduced set of peers it becomes very difficult to know who
is doing what and whom is talking to whom, the concept of
exiting/bridging to clearnet(s) is not clearly detailed in this version
but appears on the drawings
next prev parent reply other threads:[~2020-06-05 15:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2e8fba65-f7fa-4c37-a318-222547e25a06@Spark>
2020-06-03 16:20 ` Gleb Naumenko
2020-06-04 2:58 ` ZmnSCPxj
2020-06-05 10:10 ` Aymeric Vitte
2020-06-05 11:44 ` ZmnSCPxj
2020-06-05 15:41 ` Aymeric Vitte [this message]
2020-06-07 22:31 ` Antoine Riard
2020-06-08 4:56 ` ZmnSCPxj
2020-06-08 16:43 ` Aymeric Vitte
2020-06-10 23:34 ` ZmnSCPxj
2020-06-11 9:21 ` Antoine Riard
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=03508424-639f-2f3f-8b0e-5b1013f5269a@gmail.com \
--to=vitteaymeric@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=naumenko.gs@gmail$(echo .)com \
/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