Simplify versioning system for user guides
This new approach doesn't require version numbers and make easier for contributors to understand the status
of the document. There are only 3 states:
- Outdated: The page is outdated and might not work as expected
- Untranslated: The page needs to be translated
- Translation outdated: The page is translated, but the original (English) document has been updated
To mark a guide as outdated, we change the boolean of the front matter entry 'outdated' in /resources/user-guides/GUIDE.
If 'False', the guide is updated. If 'True' all versions of the guide (English included) will show a warning at the bottom
of the page.
The other 2 states are related to the status of the translated pages and we control them from the language-specific
user guides: /_i18n/LANG/resources/user-guides/GUIDE. At the top of the page a snippet will include 2 parameters:
- translated: "yes" if the page is translated, "no" if it's not.
- translationOutdated: "yes" if the translation is outdated, "no" if it's not
This new system aims to be simpler than the precedent, avoiding to compare versioning numbers and using a higher level
system instead (yes, no, True, False). I also removed the middle way status 'only minor changes', because if there are
only minor changes that don't affect the usability of the guide, we don't need to point it out.
The old system was complex and people didn't use it. These changes will hopefully make things easier for translators and
other contributors.
2020-05-03 13:38:01 +00:00
|
|
|
{% include disclaimer.html translated="no" translationOutdated="no" %}
|
|
|
|
|
|
2018-05-13 22:28:58 +00:00
|
|
|
### Prove payments
|
|
|
|
|
|
2017-12-05 19:43:20 +00:00
|
|
|
When you send money to a party who then disputes the payment was made, you need to be able to prove the payment was made.
|
|
|
|
|
|
|
|
|
|
With Bitcoin, this is typically done by looking up the transaction ID, where the origin and destination addresses are
|
|
|
|
|
shown, along with the amount transacted.
|
|
|
|
|
|
|
|
|
|
Monero, however, is private: that information is not available publicly on the blockchain. The steps are therefore a bit
|
|
|
|
|
more involved.
|
|
|
|
|
|
|
|
|
|
To prove to Charlie that she made a payment to Bob, Alice must supply Charlie three pieces of information:
|
|
|
|
|
|
|
|
|
|
- the transaction ID, as is done in Bitcoin
|
|
|
|
|
- Bob's address, as is done with Bitcoin
|
|
|
|
|
- the transaction's key, which is new with Monero and other CryptoNote currencies
|
|
|
|
|
|
2018-05-13 22:28:58 +00:00
|
|
|
When Alice made the transaction, a one time key was automatically generated just for this transaction.
|
|
|
|
|
|
|
|
|
|
#### CLI
|
|
|
|
|
|
|
|
|
|
Alice can query it thus in monero-wallet-cli (new name for the old simplewallet):
|
2017-12-05 19:43:20 +00:00
|
|
|
|
|
|
|
|
> get_tx_key TXID
|
|
|
|
|
|
|
|
|
|
Alice would plug in her actual transaction ID instead of this TXID placeholder. All being well, the one time transaction key
|
|
|
|
|
will be displayed.
|
|
|
|
|
|
|
|
|
|
Note that this will only work if monero-wallet-cli is set to save transaction keys. To double check:
|
|
|
|
|
|
|
|
|
|
> set
|
|
|
|
|
|
|
|
|
|
If it's set to 0, set it to 1:
|
|
|
|
|
|
|
|
|
|
> set store-tx-info 1
|
|
|
|
|
|
2018-05-13 22:28:58 +00:00
|
|
|
#### GUI
|
2017-12-05 19:43:20 +00:00
|
|
|
|
2018-05-13 22:28:58 +00:00
|
|
|
Alice can open her monero-wallet-gui and go to the history page to see her transaction detail:
|
|
|
|
|
|
2020-10-31 14:42:04 +00:00
|
|
|
|
2018-05-13 22:28:58 +00:00
|
|
|
|
|
|
|
|
Here, she can copy the transaction ID and Bob's address by clicking on each of them.
|
|
|
|
|
Then she can click on `P` to get a payment proof (transaction key):
|
|
|
|
|
|
2020-10-31 14:42:04 +00:00
|
|
|
|
2017-12-05 19:43:20 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
2018-05-13 22:28:58 +00:00
|
|
|
Alice can now send Charlie the transaction key along with transaction ID and Bob's address.
|
|
|
|
|
|
|
|
|
|
Note: if several transactions were made, this needs repeating for each such transaction.
|
|
|
|
|
|
|
|
|
|
### Check payments
|
|
|
|
|
|
2017-12-05 19:43:20 +00:00
|
|
|
Charlie now received those three pieces of information, and wants to check Alice is telling the truth: on an up to date
|
2018-05-13 22:28:58 +00:00
|
|
|
blockchain,
|
|
|
|
|
|
|
|
|
|
#### CLI
|
|
|
|
|
|
|
|
|
|
Charlie types in monero-wallet-cli:
|
2017-12-05 19:43:20 +00:00
|
|
|
|
|
|
|
|
> check_tx_key TXID TXKEY ADDRESS
|
|
|
|
|
|
|
|
|
|
The information supplied by Alice plugs neatly instead of the placeholders. monero-wallet-cli will use the transaction
|
|
|
|
|
key to decode the transaction, and display how much this particular transaction sent to this address. Obviously,
|
|
|
|
|
Charlie will want to double check with Bob the address is really his - same as with Bitcoin.
|
|
|
|
|
|
2018-05-13 22:28:58 +00:00
|
|
|
#### GUI
|
2017-12-05 19:43:20 +00:00
|
|
|
|
2018-05-13 22:28:58 +00:00
|
|
|
Charlie will open his monero-wallet-gui and go to the Advanced > Prove/Check page to fill the Check section with the informations provided by Alice:
|
|
|
|
|
|
2020-10-31 14:42:04 +00:00
|
|
|
|
2018-05-13 22:28:58 +00:00
|
|
|
|
|
|
|
|
Then clicking on Check will tell Charlie how much this particular transaction sent to this address, and how much confirmation the transaction had:
|
2017-12-05 19:43:20 +00:00
|
|
|
|
2020-10-31 14:42:04 +00:00
|
|
|
|
2017-12-05 19:43:20 +00:00
|
|
|
|
2018-05-13 22:28:58 +00:00
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
Obviously, Charlie will want to double check with Bob the address is really his - same as with Bitcoin.
|
|
|
|
|
|
|
|
|
|
Note: if several transactions were made, this needs repeating for each such transaction.
|
