Updated docs for node start-up, tokens, and transactions by royster57 · Pull Request #120 · mintlayer/core

royster57 · 2021-11-15T05:28:51Z

No description provided.

iljakuklic · 2021-11-15T08:30:27Z

docs/README.md

+    --validator 			\
+    --rpc-external 			\
+    --rpc-methods Unsafe 		\
+    --chain=Testnet1Spec.json


I never used the --rpc-external and --rpc-methods Unsafe options so at least for basic usage, these are not necessary. The question is whether users should pass them by default. Ideally, the command to run the node should be as simple as possible.

If I understand correctly, the rpc-external flag binds to all network interfaces with IP 0.0.0.0, meaning that anyone can connect to the node from outside the network. And rpc-methods Unsafe, basically allows anyone connecting to the RPC to be an owner of the node, and hence, expose keys. Meaning: We're basically exposing everything to everyone and allowing anyone connecting to RPC to do whatever they want... what's the logic behind this?! Did we try not adding them and had problems?

This is the command to run as I understood it from Amin.
@zorvan What do you think of Lukas's and Sam's comments?

They are right. Latest version of cli switches for user and production id reaped off from those.

@zorvan so what is the correct command? Should I simply remove --rpc-external and --rpc-methods Unsafe?

As in every issue in programming, that depends on what you want to do. The right solution, in my opinion, is to remove these and tell the user that they will be binding to localhost, hence, no connections from the outside will be possible and explain that this is a safety procedure and using tunnels is usually better than opening to the outside, and then explain that unsafe methods will not work unless the user enables them.

And let me explain that hacks with externally accessible RPC happened before:

https://www.coindaily.co/2801-2/

sinitcin · 2021-11-16T10:51:40Z

docs/tokens.md

+
+A transaction involving transaction output carries a (possibly empty) `data` field specifying the purpose of the transaction.
+
+**TOOD when is there no data field?**


Should be here TODO instead of TOOD?

sinitcin · 2021-11-16T10:52:28Z

docs/tokens.md

+
+**TOOD when is there no data field?**
+
+The data field can be any of the fol


sinitcin · 2021-11-16T11:00:25Z

docs/tokens.md

+
+**TODO is the sentence below true? In the example, I don't see any data relating to the token in the input.** 
+
+When issuing a new token, we specify the data for creating a new token in the transaction input, where the `token_id` is a hash of the inputs.


When issuing a new token, we specify the data for creating a new token in the transaction output. After that, a wallet should calculate the token_id that is a hash of the first input of the issuance transaction. And use this token_id is able to send tokens to anyone.

Thanks, that clarifies things! I will modify the explanation.

sinitcin · 2021-11-16T11:04:30Z

docs/tokens.md

+
+When issuing a new token, we specify the data for creating a new token in the transaction input, where the `token_id` is a hash of the inputs.
+
+**TODO explain the remaining fields (token_ticker, metadata_URI)**


token_ticker is a short name of the token. No longer than 5 symbols.

metadata_URI is a web link to a JSON file where we can store additional information for the token: #67 Over here you can find the paragraph: Format of data located by reference metadata_URI

@sinitcin Which characters can be used in the token ticker? Are numbers, special characters allowed?

sinitcin · 2021-11-16T11:08:37Z

docs/tokens.md

+
+**TODO explain the remaining fields (token_ticker, metadata_URI)**
+
+**TODO the token issuance struct shown here has a token_id which does not appear in the example. In staging, this is commented out. Why?**


During the review process, Sam tell me that I have to remove token_id in TokenIssuanceV1 because it's a calculatable field from an of the first input. I will clear comments.

royster57 requested review from TheQuantumPhysicist, erubboli, iljakuklic, muursh and zorvan as code owners November 15, 2021 05:28

royster57 force-pushed the roy/docs_no_wallet_fix branch 2 times, most recently from 33ca63d to 32b5652 Compare November 15, 2021 08:06

iljakuklic reviewed Nov 15, 2021

View reviewed changes

zorvan approved these changes Nov 15, 2021

View reviewed changes

sinitcin reviewed Nov 16, 2021

View reviewed changes

royster57 force-pushed the roy/docs_no_wallet_fix branch 5 times, most recently from b8767ec to 838dc5d Compare November 22, 2021 07:43

TheQuantumPhysicist approved these changes Nov 22, 2021

View reviewed changes

Updated docs for node start-up, tokens, and transactions

5cc65bb

royster57 force-pushed the roy/docs_no_wallet_fix branch from 838dc5d to 5cc65bb Compare November 22, 2021 09:37

muursh approved these changes Nov 22, 2021

View reviewed changes

royster57 merged commit 7b34458 into staging Nov 23, 2021


		A transaction involving transaction output carries a (possibly empty) `data` field specifying the purpose of the transaction.

		TOOD when is there no data field?


		TOOD when is there no data field?

		The data field can be any of the fol


		TODO is the sentence below true? In the example, I don't see any data relating to the token in the input.

		When issuing a new token, we specify the data for creating a new token in the transaction input, where the `token_id` is a hash of the inputs.


		When issuing a new token, we specify the data for creating a new token in the transaction input, where the `token_id` is a hash of the inputs.

		TODO explain the remaining fields (token_ticker, metadata_URI)


		TODO explain the remaining fields (token_ticker, metadata_URI)

		TODO the token issuance struct shown here has a token_id which does not appear in the example. In staging, this is commented out. Why?

Conversation

royster57 commented Nov 15, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants