Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

to-do list #1

Open
1 of 6 tasks
6102bitcoin opened this issue May 10, 2021 · 4 comments
Open
1 of 6 tasks

to-do list #1

6102bitcoin opened this issue May 10, 2021 · 4 comments

Comments

@6102bitcoin
Copy link
Contributor

6102bitcoin commented May 10, 2021

@6102bitcoin 6102bitcoin changed the title To-Add to-do list May 15, 2021
@nyxnor
Copy link

nyxnor commented Jun 14, 2021

EPS style new peer for broadcasting locally in a private way

Style random-peer from jm (but not really close, as there is no other parties here):
JoinMarket-Org/joinmarket-clientserver@7f62bfe
If broadcasting through your own node, you can create dedicated tor instances https://coderwall.com/p/01_gpg/multiple-instance-of-torm, so you just renew their circuit to broadcast, instead of the main service using 9051, leaving it untouched. But following this, would need to declare the control port below, as stem will recognize the default port and use it to signal.newnym

Remove need for control port to refresh tor?

What if I say you can just not mention the port?

with Controller.from_port(port=9051) as controller:

Nyx uses tor_controller port imported from Stem https://gitweb.torproject.org/nyx.git/tree/nyx/panel/header.py#n105, using the default port.

with Controller.from_port() as controller:

@6102bitcoin
Copy link
Contributor Author

Interesting cheers!

  • Any advice on how to best implement random-peer?
  • Great to know about the lack of need to mention the port! Does this mean we don't need to get the tor password?

@nyxnor
Copy link

nyxnor commented Jun 14, 2021

Any advice on how to best implement random-peer?

Reading the var description again, does not fit txCast right now, as it is possible only if there are more parties involved with the same configuration to accept it.

Great to know about the lack of need to mention the port! Does this mean we don't need to get the tor password?

If you hash the password, you need to input every time or save into a variable inside the file for organization, but this would kill the objective of hashing the password if you save it in plain text.
Using CookieAuthentication 1 solves this, no password needed, authenticate will be blank

controller.authenticate(password=tor_password)

controller.authenticate()

There is debate about using Cookies or Hashed password. Mention in the torrc manual.

  • Hash -> if they present the password whose one-way hash (no disclaimers about it)
  • Cookie -> when the connecting process knows the contents of a file named "control_auth_cookie" ... should only be used on systems with good filesystem security

Summary

from this:

ControlPort 9051
HashedControlPassword 16:32F851C1593A6DBC60B8E1E33AA9557B0F7A2E63297F6DCD6C18E61C50
from stem import Signal
from stem.control import Controller

with Controller.from_port(port = 9051) as controller:
  controller.authenticate(password=tor_password)
  controller.signal(Signal.NEWNYM)

to this

ControlPort 9051
CookieAuthentication 1
from stem import Signal
from stem.control import Controller

with Controller.from_port() as controller:
  controller.authenticate()
  controller.signal(Signal.NEWNYM)

Regarding automation

Very cool what you did, as I can see, you managed to keep it compatible with different systems, but I still think it can be automated to just asking for tx at maximum. Following this, just remains to input tx:

  • Endpoint should be random, humans follow patterns
  • Save maximum delay inside .py
  • network and rpc infos should be extracted from bitcoin.conf or written inside .py

One thing I think can be enhanced, is comparing IPs with Tor before and after signaling newnym, to check it it differentiate, this would provide 100% accuracy to check if it worked. Yes, there is this error handling, if connection was refused, maybe ok?

Actually, this is based on the exit node, and the exit node can be the same sometimes but the circuit change, this probability is lower nowadays, but won't say it is impossible. Worth checking out circuits here https://stem.torproject.org/tutorials/down_the_rabbit_hole.html

@6102bitcoin
Copy link
Contributor Author

This is very useful. Thank you for doing this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants