cirocosta / go-monero Goto Github PK

it'd be great if one could control monerod in a declarative manner when it comes to bans, specially if we consider the monero-operator usecase.

$ monero daemon set-bans -f ./bans.csv

where bans.csv

1.2.3.4,720h

• dh

there are some ints where it should be uint64 ... might as well just go through all of them at once in a second review

when using tor, I think we're not really getting the best results (if you look at the errors, you can tell there's a bunch of SOCKS Unknown Error, or some TTLs too).

it might be wise to add some retry logic for some of these errors (or just a very permissive catch-all to try again?)

#17 introduced

      --shorten-addresses          whether addresses should be shortened when displaying pretty results (default true)

as a "global" flag for daemon and wallet subcommands, it'd be good to ensure that we retrieve make use of the options formatter in every place where addresses are returned

16 outs max is only a bproof limit, so p2p can (and probably will) generate some interesting txns that are 16+ outs - e.g., see https://xmrchain.net/tx/e67064ac25cf73a91291e9b89943c3f3c84ff948e663ddec6dd15afbc98ed0d7 from p2pool

• setup tor proxy
• figure out i2p? never used it
• setup a full node in both
• figure out go support for socks proxy (I guess that's how we could make what we have "just work"?)

uuh, this is sick: https://github.com/ipsn/go-libtor
w/ regards to proxy'in, yeah, sounds very simple indeed: https://gist.github.com/Yawning/bac58e08a05fc378a8cc

levin-related: when reading from the tcp sockets that get created for each host, we should enforce some deadlines in order to make sure the opposite of a slow-loris is taking place by a tweaked server

for some commands, showing the full address forces the user to make their terminals pretty wide

e.g.

$ monero wallet get-accounts
Total Balance:          390311543905607
Total Unlocked Balance: 390311543905607

        LABEL           TAG     ADDR                                                                                            BALANCE         UNLOCKED BALANCE
0       Primary account         53G25UfvJkvKZpJk3LgKTebdLwcxVQxSrWcwLHJUtWYHPZX6PrwggUN1PisbZG81YkJNVEgpCUMBKE8Dkaqn4CpsPUA91AX 389311543905607 389311543905607
1       test                    72vD5orMS7tVykwtGHcCJVK5zzqL6h3jwb3spQBYR5qQVRcs2Jx1SQzWHozsqQqjWnKrrYE2MLiNu6PwwGQukm6nTk43SXV 1000000000000   1000000000000

requires 160 chars

but, if we were to reduce those addresses to include just the first and last 5 chars, then we get down to ~80

Total Balance:          390311543905607
Total Unlocked Balance: 390311543905607

        LABEL           TAG     ADDR           BALANCE         UNLOCKED BALANCE
0       Primary account         53G25...A91AX  389311543905607 389311543905607
1       test                    72vD5...43SXV  1000000000000   1000000000000

we could include an extra flag passed down to the pretty printers to toggle such behavior, something like --wrap which would be true by default?

some of the pretty prints are not really consistent: in some places, we should atomic unics, in others, ɱ. In some places, KiB, in others, KB ... let's make sure these units are consistent

0. tx public key
1. ring members & corresponding blocks (depends on /get_outs)
2. timescale

introduced in 9536d94

so we can handle

  --rpc-login arg                       Specify username[:password] required

get block count: jsonrpc: submit request: decode: json: cannot unmarshal number 18446744073709551615 into Go struct field GetInfoResult.result.free_space of type int64

from

MONERO_ADDRESS=http://localhost:18089 monero daemon get-info -v
GET /json_rpc HTTP/1.1
Host: localhost:18089
User-Agent: Go-http-client/1.1
Content-Length: 46
Content-Type: application/json
Accept-Encoding: gzip

{"id":"0","jsonrpc":"2.0","method":"get_info"}
HTTP/1.1 200 Ok
Content-Length: 1414
Accept-Ranges: bytes
Content-Type: application/json
Last-Modified: Tue, 03 Aug 2021 20:51:18 GMT
Server: Epee-based

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "adjusted_time": 1621218384,
    "alt_blocks_count": 0,
    "block_size_limit": 600000,
    "block_size_median": 300000,
    "block_weight_limit": 600000,
    "block_weight_median": 300000,
    "bootstrap_daemon_address": "",
    "busy_syncing": true,
    "credits": 0,
    "cumulative_difficulty": 106481972508558381,
    "cumulative_difficulty_top64": 0,
    "database_size": 112742891520,
    "difficulty": 320281691384,
    "difficulty_top64": 0,
    "free_space": 18446744073709551615,
    "grey_peerlist_size": 0,
    "height": 2362612,
    "height_without_bootstrap": 0,
    "incoming_connections_count": 0,
    "mainnet": true,
    "nettype": "mainnet",
    "offline": false,
    "outgoing_connections_count": 0,
    "rpc_connections_count": 0,
    "stagenet": false,
    "start_time": 0,
    "status": "OK",
    "synchronized": false,
    "target": 120,
    "target_height": 2419228,
    "testnet": false,
    "top_block_hash": "fa5d998295a00c1dc8f8189d1dfbcd3737125f9c4a69fffdfb3d579dcf26a6cb",
    "top_hash": "",
    "tx_count": 13626918,
    "tx_pool_size": 1,
    "untrusted": false,
    "update_available": false,
    "version": "",
    "was_bootstrap_ever_used": false,
    "white_peerlist_size": 0,
    "wide_cumulative_difficulty": "0x17a4cca325b042d",
    "wide_difficulty": "0x4a9246c4f8"
  }
}

from monero-project/monero#7089

The current default SSL security policy of the monero-wallet-cli and monero-wallet-rpc is to autodetect whether the daemon RPC has SSL enabled. A root-CA check against the domain is attempted, but only a warning is logged if it fails. The root-CA validation is not mandatory with autodect because an attacker can mitm the connection to downgrade to cleartext. A connection must be SSL mandatory for peer authentication; DANE/TLSA was created to solve the opportunistic encryption failures of SMTP.

...

Proposal 2: Add DANE/TLSA support to the wallet autodetect mode. Its basically completed, for better or worse. Domains can "opt-in" by putting SHA256 or SHA512 fingerprints of their self-signed certificates in DNSSEC records. Domains that do not have this DNSSEC record have no change. The fingerprint could also be cached locally in the wallet data for an improved trust-on-first-use mode. The domain can set an expiry longer than 3 months for $0. The security is based on the TLD, registrar, and ICANN. So not nation-state proof, but average miscreant proof. Hopefully more difficult than root-CA shenanigans, but subjective.

(reference implem: monero-project/monero@af252c0)

https://datatracker.ietf.org/doc/html/rfc6698

it does what's supposed to do, but:

• the types kinda suck
• it's very specific solely to levin's handshake command

it served us well for creating the tor/i2p/clearnet p2p crawler, but it deserves some TLC

https://www.getmonero.org/resources/developer-guides/daemon-rpc.html#get_peer_list

given that we have included the necessary crypto utils for generating the primary address, we could keep going and add support for subaddresses, which is not very far off.

from monero-project/monero#2056

I imagine we could do so by either extending the interface of Seed with an extra method Subaddress(major, minor uint32) []byte (1) or getting rid of PrimaryAddress() []byte and having only the subaddress one considering major=0,minor=0 the case for PrimaryAddress (2).

imo, (1) is the way to go.

m = Hs(a || i)
M = m*G
D = B + M
C = a*D

being

• a being the master private view key
• Hs being Keccak-256 with || representing the concatenation
• G the base point of he ed25519 curve per cryptonote's paper
• B being the master public spend key
• C and D the generated public view and public spend keys that can be composed together to form the final address using the same method as we do for a primary address
• * being scalar multiplication
• + being compressed addition

currently, if one decides to use -x to provide the socks5 address of their local tor client and connect to a public node they know by name (say, node.melo.tools), a DNS leak will occur as Go will issue a dns query for node.melo.tools over clearnet ignoring the proxy.

keeping our paranoid hats on, we should provide the ability for folks to specify that the DNS resolution should be carried over tcp passing through our proxy (so that we can resolve, e.g., using dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion:443 aka cloudflare's dns over https as a hidden service or somethign else)

at the moment, all we do is output the json representation of the internal structures that we have in go structs.

given that we already have -v to put under stderr the json as it goes through the wire, let's make the cli pretty 💅

Hello @cirocosta, want to say thank you for your time and effort put into this project.
I'm mostly interested in the Levin Protocol Implementation and have been digging around to try and understand the implementation at hand.
My problem is as follows:

l, err := levin.NewPortableStorageFromBytes(buff) 
if err != nil {
log.Fatal(err)
for x := range l.Entries {
      fmt.Println(x) 
    }
}

Have tested this against a few binary(levin) RPC request/responce messages generated from the official monero RPC client connected to the test network and every time I try to decode them I get panic: unknown ttype b
After analyzing https://github.com/cirocosta/go-monero/blob/master/pkg/levin/portable_storage.go#L204 and comparing to the defined constants BoostSerializeType*, I come to the conclusion that a few methods are still missing for this to be complete, in this case BoostSerializeTypeBool.

Is my assumption correct?
From your point of view and experience can you express in percentage how complete this implementation is ?
Do you have some examples that I can try in case I'm using the library in the wrong way?

Thank you for your time.

it doesn't make a whole lot of sense to have the crawler implemented here, let's move it to somewhere else