Added incoming_transfers RPC API method #23

paybee · 2014-06-02T22:30:40Z

As needed by exchanges etc. Also cleaned up the RPC map somewhat.

Added incoming_transfers RPC API method

Disable checking for DNS seed nodes

boost::asio::ssl::context is created using specifically TLSv1.2, which blocks the ability to use superior version of TLS like TLSv1.3. Filtering is also made specially later in the code to remove unsafe version for TLS such SSLv2, SSLv3 etc.. This change is removing double filtering to allow TLSv1.2 and above to be used. testssl.sh 3.0rc5 now reports the following (please note monerod was built with USE_EXTRA_EC_CERT): $ ./testssl.sh --openssl=/usr/bin/openssl \ --each-cipher --cipher-per-proto \ --server-defaults --server-preference \ --vulnerable --heartbleed --ccs --ticketbleed \ --robot --renegotiation --compression --breach \ --poodle --tls-fallback --sweet32 --beast --lucky13 \ --freak --logjam --drown --pfs --rc4 --full \ --wide --hints 127.0.0.1:38081 Using "OpenSSL 1.1.1d 10 Sep 2019" [~80 ciphers] on ip-10-97-15-6:/usr/bin/openssl (built: "Dec 3 21:14:51 2019", platform: "linux-x86_64") Start 2019-12-03 21:51:25 -->> 127.0.0.1:38081 (127.0.0.1) <<-- rDNS (127.0.0.1): -- Service detected: HTTP Testing protocols via sockets except NPN+ALPN SSLv2 not offered (OK) SSLv3 not offered (OK) TLS 1 not offered TLS 1.1 not offered TLS 1.2 offered (OK) TLS 1.3 offered (OK): final NPN/SPDY not offered ALPN/HTTP2 not offered Testing for server implementation bugs No bugs found. Testing cipher categories NULL ciphers (no encryption) not offered (OK) Anonymous NULL Ciphers (no authentication) not offered (OK) Export ciphers (w/o ADH+NULL) not offered (OK) LOW: 64 Bit + DES, RC[2,4] (w/o export) not offered (OK) Triple DES Ciphers / IDEA not offered (OK) Average: SEED + 128+256 Bit CBC ciphers not offered Strong encryption (AEAD ciphers) offered (OK) Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4 PFS is offered (OK), ciphers follow (client/browser support is important here) Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) ----------------------------------------------------------------------------------------------------------------------------- x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256 xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 xcca9 ECDHE-ECDSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256 xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519 X448 Testing server preferences Has server cipher order? yes (OK) Negotiated protocol TLSv1.3 Negotiated cipher TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Cipher order TLSv1.2: ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.3: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 Testing server defaults (Server Hello) TLS extensions (standard) "renegotiation info/#65281" "EC point formats/monero-project#11" "supported versions/monero-project#43" "key share/monero-project#51" "max fragment length/monero-project#1" "extended master secret/monero-project#23" Session Ticket RFC 5077 hint no -- no lifetime advertised SSL Session ID support yes Session Resumption Tickets no, ID: no TLS clock skew Random values, no fingerprinting possible Server Certificate monero-project#1 (in response to request w/o SNI) Signature Algorithm SHA256 with RSA Server key size RSA 4096 bits Server key usage -- Server extended key usage -- Serial / Fingerprints 01 / SHA1 132E42981812F5575FA0AE64922B18A81B38C03F SHA256 EBA3CC4AA09DEF26706E64A70DB4BC8D723533BB67EAE12B503A845019FB61DC Common Name (CN) (no CN field in subject) subjectAltName (SAN) missing (NOT ok) -- Browsers are complaining Issuer Trust (hostname) certificate does not match supplied URI Chain of trust NOT ok (self signed) EV cert (experimental) no "eTLS" (visibility info) not present Certificate Validity (UTC) 181 >= 60 days (2019-12-03 21:51 --> 2020-06-02 21:51) # of certificates provided 1 Certificate Revocation List -- OCSP URI -- NOT ok -- neither CRL nor OCSP URI provided OCSP stapling not offered OCSP must staple extension -- DNS CAA RR (experimental) not offered Certificate Transparency -- Server Certificate monero-project#2 (in response to request w/o SNI) Signature Algorithm ECDSA with SHA256 Server key size EC 256 bits Server key usage -- Server extended key usage -- Serial / Fingerprints 01 / SHA1 E17B765DD8124525B1407E827B89A31FB167647D SHA256 AFB7F44B1C33831F521357E5AEEB813044CB02532143E92D35650A3FF792A7C3 Common Name (CN) (no CN field in subject) subjectAltName (SAN) missing (NOT ok) -- Browsers are complaining Issuer Trust (hostname) certificate does not match supplied URI Chain of trust NOT ok (self signed) EV cert (experimental) no "eTLS" (visibility info) not present Certificate Validity (UTC) 181 >= 60 days (2019-12-03 21:51 --> 2020-06-02 21:51) # of certificates provided 1 Certificate Revocation List -- OCSP URI -- NOT ok -- neither CRL nor OCSP URI provided OCSP stapling not offered OCSP must staple extension -- DNS CAA RR (experimental) not offered Certificate Transparency -- Testing HTTP header response @ "/" HTTP Status Code 404 Not found (Hint: supply a path which doesn't give a "404 Not found") HTTP clock skew Got no HTTP time, maybe try different URL? Strict Transport Security not offered Public Key Pinning -- Server banner Epee-based Application banner -- Cookie(s) (none issued at "/") -- maybe better try target URL of 30x Security headers -- Reverse Proxy banner -- Testing vulnerabilities Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension CCS (CVE-2014-0224) not vulnerable (OK) Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK), no session ticket extension ROBOT Server does not support any cipher suites that use RSA key transport Secure Renegotiation (CVE-2009-3555) not vulnerable (OK) Secure Client-Initiated Renegotiation not vulnerable (OK) CRIME, TLS (CVE-2012-4929) not vulnerable (OK) BREACH (CVE-2013-3587) no HTTP compression (OK) - only supplied "/" tested POODLE, SSL (CVE-2014-3566) not vulnerable (OK) TLS_FALLBACK_SCSV (RFC 7507) No fallback possible, no protocol below TLS 1.2 offered (OK) SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK) FREAK (CVE-2015-0204) not vulnerable (OK) DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK) make sure you don't use this certificate elsewhere with SSLv2 enabled services https://censys.io/ipv4?q=EBA3CC4AA09DEF26706E64A70DB4BC8D723533BB67EAE12B503A845019FB61DC could help you to find out LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2 BEAST (CVE-2011-3389) no SSL3 or TLS1 (OK) LUCKY13 (CVE-2013-0169), experimental not vulnerable (OK) RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK) Testing ciphers per protocol via OpenSSL plus sockets against the server, ordered by encryption strength Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) ----------------------------------------------------------------------------------------------------------------------------- SSLv2 SSLv3 TLS 1 TLS 1.1 TLS 1.2 xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 xcca9 ECDHE-ECDSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS 1.3 x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256 x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256 Running client simulations (HTTP) via sockets Browser Protocol Cipher Suite Name (OpenSSL) Forward Secrecy ------------------------------------------------------------------------------------------------ Android 4.2.2 No connection Android 4.4.2 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256) Android 5.0.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 256 bit ECDH (P-256) Android 6.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 256 bit ECDH (P-256) Android 7.0 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305 253 bit ECDH (X25519) Android 8.1 (native) No connection Android 9.0 (native) TLSv1.3 TLS_AES_256_GCM_SHA384 253 bit ECDH (X25519) Chrome 65 Win 7 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305 253 bit ECDH (X25519) Chrome 74 (Win 10) No connection Firefox 62 Win 7 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305 253 bit ECDH (X25519) Firefox 66 (Win 8.1/10) TLSv1.3 TLS_AES_256_GCM_SHA384 253 bit ECDH (X25519) IE 6 XP No connection IE 7 Vista No connection IE 8 Win 7 No connection IE 8 XP No connection IE 11 Win 7 No connection IE 11 Win 8.1 No connection IE 11 Win Phone 8.1 No connection IE 11 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256) Edge 15 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 253 bit ECDH (X25519) Edge 17 (Win 10) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 253 bit ECDH (X25519) Opera 60 (Win 10) No connection Safari 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256) Safari 9 OS X 10.11 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256) Safari 10 OS X 10.12 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256) Apple ATS 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256) Tor 17.0.9 Win 7 No connection Java 6u45 No connection Java 7u25 No connection Java 8u161 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256) Java 9.0.4 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256) OpenSSL 1.0.1l TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256) OpenSSL 1.0.2e TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256) OpenSSL 1.1.0j (Debian) TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305 253 bit ECDH (X25519) OpenSSL 1.1.1b (Debian) TLSv1.3 TLS_AES_256_GCM_SHA384 253 bit ECDH (X25519) Thunderbird (60.6) TLSv1.3 TLS_AES_256_GCM_SHA384 253 bit ECDH (X25519)

…idator-list-multisignatures Multi-sign validator lists for extra security

Implement async wallet scanner. Adds a new functional test for direct wallet2 -> live RPC daemon interactions. This sets up a framework to test pointing the Seraphis wallet lib to a live daemon. Tests sending and scanning: - a normal transfer - a sweep single (0 change) - to a single subaddress - to 3 subaddresses (i.e. scanning using additional pub keys) * scan machine: option to force reorg avoidance increment first pass - when pointing to a daemon that does not support returning empty blocks when the client requests too high of a height, we have to be careful in our scanner to always request blocks below the chain tip, in every request. - by forcing the reorg avoidance increment on first pass, we make sure clients will always include the reorg avoidance increment when requesting blocks from the daemon, so the client can expect the request for blocks should *always* return an ok height. * core tests: check conversion tool on all legacy enote version types Stil TODO: - check complete scanning on all enote types - hit every branch condition for all enote versions * conn pool mock: epee http client connection pool - Enables concurrent network requests using the epee http client. - Still TODO for production: 1) close_connections 2) require the pool respect max_connections * enote finding context: IN LegacyUnscannedChunk, OUT ChunkData - finds owned enotes by legacy view scanning a chunk of blocks * async: function to remove minimum element from token queue - Useful when we want to remove elements of the token queue in an order that is different than insertion order. * async scanner: scan via RPC, fetching & scanning parallel chunks *How it works* Assume the user's wallet must start scanning blocks from height 5000. 1. The scanner begins by launching 10 RPC requests in parallel to fetch chunks of blocks as follows: ``` request 0: { start_height: 5000, max_block_count: 20 } request 1: { start_height: 5020, max_block_count: 20 } ... request 9: { start_height: 5180, max_block_count: 20 } ``` 2. As soon as any single request completes, the wallet immediately parses that chunk. - This is all in parallel. For example, as soon as request 7 responds, the wallet immediately begins parsing that chunk in parallel to any other chunks it's already parsing. 3. If a chunk does not include a total of max_block_count blocks, and the chunk is not the tip of the chain, this means there was a "gap" in the chunk request. The scanner launches another parallel RPC request to fill in the gap. - This gap can occur because the server will **not** return a chunk of blocks greater than 100mb (or 20k txs) via the /getblocks.bin` RPC endpoint ([`FIND_BLOCKCHAIN_SUPPLEMENT_MAX_SIZE`](https://github.com/monero-project/monero/blob/053ba2cf07649cea8134f8a188685ab7a5365e5c/src/cryptonote_core/blockchain.cpp#L65)) - The gap is from `(req.start_height + res.blocks.size())` to `(req.start_height + req.max_block_count)`. 4. As soon as the scanner finishes parsing the chunk, it immediately submits another parallel RPC request. 5. In parallel, the scanner identifies a user's received (and spent) enotes in each chunk. - For example, as soon as request 7 responds and the wallet parses it, the wallet scans that chunk in parallel to any other chunks it's already scanning. 6. Once a single chunk is fully scanned locally, the scanner launches a parallel task to fetch and scan the next chunk. 7. Once the scanner reaches the tip of the chain (the terminal chunk), the scanner terminates. *Some technical highlights* - The wallet scanner is backwards compatible with existing daemons (though it would need to point to an updated daemon to realize the perf speed-up). - On error cases such as the daemon going offline, the same wallet errors that wallet2 uses (that the wallet API expects) are propagated up to the higher-level Seraphis lib. - The implementation uses an http client connection pool (reusing the epee http client) to support parallel network requests ([related](seraphis-migration/wallet3#58)). - A developer using the scanner can "bring their own blocks/network implementation" to the scanner by providing a callback function of the following type as a param to the async scanner constructor: `std::function<bool(const cryptonote::COMMAND_RPC_GET_BLOCKS_FAST::request, cryptonote::COMMAND_RPC_GET_BLOCKS_FAST::response)>` --------- Co-authored-by: jeffro256 <jeffro256@tutanota.com>

p2p: stressnet tor & i2p seed nodes

Implement async wallet scanner. Adds a new functional test for direct wallet2 -> live RPC daemon interactions. This sets up a framework to test pointing the Seraphis wallet lib to a live daemon. Tests sending and scanning: - a normal transfer - a sweep single (0 change) - to a single subaddress - to 3 subaddresses (i.e. scanning using additional pub keys) * scan machine: option to force reorg avoidance increment first pass - when pointing to a daemon that does not support returning empty blocks when the client requests too high of a height, we have to be careful in our scanner to always request blocks below the chain tip, in every request. - by forcing the reorg avoidance increment on first pass, we make sure clients will always include the reorg avoidance increment when requesting blocks from the daemon, so the client can expect the request for blocks should *always* return an ok height. * core tests: check conversion tool on all legacy enote version types Stil TODO: - check complete scanning on all enote types - hit every branch condition for all enote versions * conn pool mock: epee http client connection pool - Enables concurrent network requests using the epee http client. - Still TODO for production: 1) close_connections 2) require the pool respect max_connections * enote finding context: IN LegacyUnscannedChunk, OUT ChunkData - finds owned enotes by legacy view scanning a chunk of blocks * async: function to remove minimum element from token queue - Useful when we want to remove elements of the token queue in an order that is different than insertion order. * async scanner: scan via RPC, fetching & scanning parallel chunks *How it works* Assume the user's wallet must start scanning blocks from height 5000. 1. The scanner begins by launching 10 RPC requests in parallel to fetch chunks of blocks as follows: ``` request 0: { start_height: 5000, max_block_count: 20 } request 1: { start_height: 5020, max_block_count: 20 } ... request 9: { start_height: 5180, max_block_count: 20 } ``` 2. As soon as any single request completes, the wallet immediately parses that chunk. - This is all in parallel. For example, as soon as request 7 responds, the wallet immediately begins parsing that chunk in parallel to any other chunks it's already parsing. 3. If a chunk does not include a total of max_block_count blocks, and the chunk is not the tip of the chain, this means there was a "gap" in the chunk request. The scanner launches another parallel RPC request to fill in the gap. - This gap can occur because the server will **not** return a chunk of blocks greater than 100mb (or 20k txs) via the /getblocks.bin` RPC endpoint ([`FIND_BLOCKCHAIN_SUPPLEMENT_MAX_SIZE`](https://github.com/monero-project/monero/blob/053ba2cf07649cea8134f8a188685ab7a5365e5c/src/cryptonote_core/blockchain.cpp#L65)) - The gap is from `(req.start_height + res.blocks.size())` to `(req.start_height + req.max_block_count)`. 4. As soon as the scanner finishes parsing the chunk, it immediately submits another parallel RPC request. 5. In parallel, the scanner identifies a user's received (and spent) enotes in each chunk. - For example, as soon as request 7 responds and the wallet parses it, the wallet scans that chunk in parallel to any other chunks it's already scanning. 6. Once a single chunk is fully scanned locally, the scanner launches a parallel task to fetch and scan the next chunk. 7. Once the scanner reaches the tip of the chain (the terminal chunk), the scanner terminates. *Some technical highlights* - The wallet scanner is backwards compatible with existing daemons (though it would need to point to an updated daemon to realize the perf speed-up). - On error cases such as the daemon going offline, the same wallet errors that wallet2 uses (that the wallet API expects) are propagated up to the higher-level Seraphis lib. - The implementation uses an http client connection pool (reusing the epee http client) to support parallel network requests ([related](seraphis-migration/wallet3#58)). - A developer using the scanner can "bring their own blocks/network implementation" to the scanner by providing a callback function of the following type as a param to the async scanner constructor: `std::function<bool(const cryptonote::COMMAND_RPC_GET_BLOCKS_FAST::request, cryptonote::COMMAND_RPC_GET_BLOCKS_FAST::response)>` --------- Co-authored-by: jeffro256 <jeffro256@tutanota.com>

paybee added 4 commits May 27, 2014 12:52

Added incoming_transfers RPC API method

feacdde

Merge remote-tracking branch 'upstream/master'

0e52233

Added incoming_transfers RPC API method

295c284

fixed conflict

133019c

monero-project pushed a commit that referenced this pull request Jun 4, 2014

Merge pull request #23 from paybee/master

4492317

Added incoming_transfers RPC API method

monero-project merged commit 4492317 into monero-project:master Jun 4, 2014

moneromooo-monero mentioned this pull request Jun 26, 2017

monero-wallet-cli: hang on exit in readline code #2117

Closed

moneromooo-monero mentioned this pull request Jul 28, 2017

readline: crash on exit when late logs are printed #2217

Closed

stoffu pushed a commit to stoffu/monero that referenced this pull request Jun 3, 2018

Merge pull request monero-project#23 from stoffu/aeon-remove-seed-dns

fce2b0a

Disable checking for DNS seed nodes

dawiepoolman mentioned this pull request Oct 6, 2018

RPi3B+ monerod errors #4507

Closed

shermand100 mentioned this pull request May 19, 2020

Testing RPC pay, connected wallet-cli client ID mis-identified as inactive for negative days value, Monerod crashes with "Aborted" #6555

Closed

lxop pushed a commit to lxop/monero that referenced this pull request Jan 27, 2021

Merge pull request monero-project#23 from electroneumRepo/feature/val…

c8eccd4

…idator-list-multisignatures Multi-sign validator lists for extra security

shermand100 mentioned this pull request Dec 6, 2021

Debian Bullseye build. SIGBUS, Bus error #8098

Closed

tczee36 mentioned this pull request Jan 30, 2024

Monerod Syncing problem #9141

Closed

nahuhh pushed a commit to nahuhh/monero that referenced this pull request Aug 7, 2024

Merge pull request monero-project#23 from nahuhh/stressnet

ff948ed

p2p: stressnet tor & i2p seed nodes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added incoming_transfers RPC API method #23

Added incoming_transfers RPC API method #23

paybee commented Jun 2, 2014

Added incoming_transfers RPC API method #23

Added incoming_transfers RPC API method #23

Conversation

paybee commented Jun 2, 2014