Looks like the good folks of Monero confuse code auditability with auditability of the supply .
There is nothing wrong with being dependent on a few more mathematical assumptions like Grin and Monero, but they should be clear/factual about the assumptions in their project. And here I though Grin people were the one’s with a great fantasy using Harry Potter lore
Regarding coinbase outputs I still have questions. How, is the amount auditable by nodes?
Same for fees. I know the maturity of at least 24h is checked when spending them, but I could not find information on the grin wiki on whether their amounts are publicly visible or not. Basically, my question is how do coinbase outputs and fee outputs differ from normal outputs?
There are no “fee outputs”. Every tx transparently lists the fees it pays in its kernels. So every node can see all the fees paid in a block. Each output encodes its output type, which is either plain or coinbase [1].
I red the article. Nice explanation. I still mis information though. How does the miner claim/sign for fees and Coinbase output. It is transparently in a block but at the time of mining, the miner has to create an output with his key I assume where he signs for and proves the output he creates is equivalent to fees+block subsidy, or something similar, which can be verified by all nodes that see the new block?
I don’t really understand what your point is though? Are you saying that the math of Pedersen Commitments is so complex and mysterious that assuming it is correct is gravely naive?
If that’s the case, Grin is an extremely foolish idea. What are we all doing here?
It’s important to differentiate between different assumptions. In btc the assumption for verifying current supply is that people know how to sum up numbers (sum amounts of utxos) and that they can add and subtract numbers (I - O = 0 to verify transactions). All those assumptions are pretty safe so one could say that it’s fully auditable. In grin you need to trust EC and bulletproof cryptography and their implementations. Now sure, it can be safe, but cryptography is tricky, some gets broken over time, sometimes implementation contains a bug etc. So yeah, imo confidential transactions will (theoretically) always give you less guarantees of current supply. That doesn’t mean they’re bad or something, it’s just you get something but give up something else.
Let’s say a government throws a bunch of money into a project to do specifically that. They could then basically have their own money printer and no one would know?
Yes; they could subvert all cryptosystems relying on Pedersen commitments over secp256k1 with points G and H. Which includes Monero, Zcash, and Grin.
They just have to exercise a little care in how they spend their inflated outputs. If they take some outputs originating from under 10000 coinbases and then deposit it at an exchange as 1 million Grin, then that would expose their powers.
Been a bit busier than expected, here is the public repo for the explorer. Please let me know if the instructions in the README file are not clear. Merry Christmas everyone, wish you all the best.
I got the error below when running step number 9 ‘run docker compose -f docker-compose.production.yml run --rm django pipenv run python manage.py migrate’
File "/root/.local/share/virtualenvs/code-_Py8Si6I/lib/python3.8/site-packages/django/db/backends/postgresql/base.py", linn
connection = Database.connect(**conn_params)
File "/root/.local/share/virtualenvs/code-_Py8Si6I/lib/python3.8/site-packages/psycopg2/__init__.py", line 122, in connect
conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
django.db.utils.OperationalError: connection to server at "localhost" (127.0.0.1), port 5432 failed: Connection refused
│ connection = Database.connect(**conn_params) │
│ File "/root/.local/share/virtualenvs/code-_Py8Si6I/lib┌────────┐/site-packages/psycopg2/__init__.py", line 122, in conn │
│ conn = _connect(dsn, connection_factory=connection_f│ 0:bash │kwasync) │
│ django.db.utils.OperationalError: connection to server a└────────┘st" (127.0.0.1), port 5432 failed: Connection refused │
│ Is the server running on that host and accepting TCP/IP connections? │
Is the server running on that host and accepting TCP/IP connections?
connection to server at "localhost" (::1), port 5432 failed: Cannot assign requested address
Is the server running on that host and accepting TCP/IP connections?
Can you suggest what to solve? It seems to be related to postgresql.conf and pg_hba.conf but I can’t find them in /etc/. Thanks.
Inside of grin-explorer folder run docker compose ps and check whether postgres container is running or not (and exposing port to host). Is it possible that you’re already running postgresql on this machine for some other thing (5432 is default postgresql port)? Also check what output postgres container outputs when you run docker compose up (remember to do docker compose down before you run docker compose up).
As a side note, whoever is running this in production don’t allow 5432 through your firewall
It’s a brandnew vps so no service is running on port 5432 now, I tried ’ docker compose up and got following log and it’s staying like that for hour. Am I supposed to do something else? I tried the step 9 in different session and got same previous error.
grin-explorer-postgres-1 |
grin-explorer-postgres-1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
grin-explorer-postgres-1 |
grin-explorer-postgres-1 | 2023-12-26 00:46:15.070 UTC [1] LOG: starting PostgreSQL 16.1 (Debian 16.1-1.pgdg120+1) on x86_64-pc-lint
grin-explorer-postgres-1 | 2023-12-26 00:46:15.071 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
grin-explorer-postgres-1 | 2023-12-26 00:46:15.071 UTC [1] LOG: listening on IPv6 address "::", port 5432
grin-explorer-postgres-1 | 2023-12-26 00:46:15.074 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
grin-explorer-postgres-1 | 2023-12-26 00:46:15.079 UTC [29] LOG: database system was shut down at 2023-12-26 00:46:13 UTC
grin-explorer-postgres-1 | 2023-12-26 00:46:15.093 UTC [1] LOG: database system is ready to accept connections
grin-explorer-postgres-1 | 2023-12-26 00:51:15.190 UTC [27] LOG: checkpoint starting: time
grin-explorer-postgres-1 | 2023-12-26 00:51:15.198 UTC [27] LOG: checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 8
Ok so i’m assuming you’re doing the “production” steps. In this case, you never run docker compose up but instead docker compose -f docker-compose.production.yml up (so using a different docker compose config file). What i would do is reset the state:
docker compose down -v
docker compose -f docker-compose.production.yml down -v
Also interested in what you’ve modified in .env.prod file. Did you maybe set POSTGRES_HOST=localhost?
Once you manage to set it up i’ll update the README instructions for “production” phases (i don’t think you need to do steps 13-16 since step 8 does this now → didn’t want to force people to install nix package manager, so i’ve created a separate container which has it and init.sh uses it).
In env.prod file you should only fill in SECREY_KEY and admin user’s info (so leave POSTGRES_HOST=postgres etc). But remember to not expose postgres or redis to the internet (some OS’s are not as strict as some other, so make sure you don’t allow traffic through those ports from the internet).
And i’m confused on step 17, which parameter I should input below value of VUE_APP_BACKEND_URL in step 2?
And about the steps in ‘Setting up a blockchain’, honestly, I do not know what to do. For the moment, i got a full grin node is running in this server. Is it possible for you to input some more details for noob like me?
iptables should allow docker containers to communicate through 5432 port but not external IPs (public IPs of other people). Reason for that is because postgres has username and password “postgres” and attacker will get into your db in one minute if postgres is exposed to the outside world. I see now that in docker-compose.pruduction.yml i’ve mapped port 5432 only to the localhost so i don’t think it can be exposed to the outside world.
Yes, in step3 it says that you need to modify nginx config file (docker/nginx/conf.d/local.conf). Modification depends on whether you want to run it on a domain or just on an IP. If you want to run it on a domain then you need to:
modify both server_name values to point to your domain (eg. mygrindomain.com or whatever your domain is)
place your domain certificate’s fullchain.pem and privkey.pem in folder docker/nginx/certs/ and modify ssl_certificate to point to /etc/nginx/certs/fullchain.pem and ssl_certificate_key to point to /etc/nginx/certs/privkey.pem.
If you instead don’t want to use a domain do this:
remove this:
server {
listen 80;
server_name grin.com;
return 301 https://$host$request_uri;
}
change listen 443 to listen 0.0.0.0:80
remove ssl on, ssl_certificate and ssl_certificate_key lines
set server_name to 123.123.123.123 (if 123.123.123.123 is public IP of the server running grin explorer)
The nginx error you’re getting suggests that something is already running on port 443 i think, so check that (maybe you need to do docker compose -f docker-compose.production.yml down to shut down the previous nginx container or you have something else running on this port).
Yeah sorry, bad instructions. What you should put here if you have your own domain named mygrindomain.com is: VUE_APP_BACKEND_URL=https://mygrindomain.com/api/`. If you don’t have domain and your server is running on ip 123.123.123.123 then put VUE_APP_BACKEND_URL=http://123.123.123.123/api/`.
Once your grin-explorer page is running there are 3 dots on the top right. Click them → click login → enter admin user/pw → then you get a new settings tab (alongside blocks and graph). There you first add a node, then create a blockchain which you link with the added node. Then you click bootstrap to start syncing the explorer’s newly added blockchain with the connected node (explorer actually fetches all blocks from the node to prevent node spam and to have a better “search” functionality).
I’ll redo the readme based on the problems you face when you manage to set it up. Sorry for the inconveniences, you can msg me on keybase if you want a non-public communication. Thanks for trying it
.
