http://www.mochiwiki.com/w/api.php?action=feedcontributions&user=NickP05&feedformat=atomMochimo Wiki - User contributions [en]2024-03-29T15:57:20ZUser contributionsMediaWiki 1.31.1http://www.mochiwiki.com/w/index.php?title=TestNet&diff=572TestNet2021-07-06T19:48:15Z<p>NickP05: As a trouble emerged on discord #testnet on 06/7/2021 included the resolution that came out. https://discord.com/channels/460867662977695765/521428137481994251/861625235300286494</p>
<hr />
<div>== TestNet Overview ==<br />
TestNet Operates on TCP Port 2096, which differs from the Main Net, which is port 2095. When starting a Linux node on TestNet, please complete the following steps. First modify the coreip.lst file in the bin/ directory to be as below:<br />
<br />
217.160.249.155<br />
82.223.196.218<br />
74.208.137.73<br />
213.171.215.12<br />
<br />
Then we recommend you use the following startup line from the bin/ directory:<br />
<br />
./gomochi d -p2096 -ccoreip.lst -q2 -D &<br />
<br />
== List of Testnet Resources ==<br />
<br />
===== Dedicated Nodes =====<br />
The following four nodes are dedicated for transaction relaying and solving. Note they are CPU nodes only, so the TestNet difficulty is low (15-19) most of the time unless someone runs it up with a GPU rig.<br />
<BR><BR><br />
testnet-1.mochimo.com<BR><br />
testnet-2.mochimo.com<BR><br />
testnet-3.mochimo.com<BR><br />
testnet-4.mochimo.com<BR><br />
<br />
===== Block Explorer =====<br />
<br />
TestNet has a dedicated block explorer for viewing live blocks on the network. You can find the testnet BX at: http://testnet-bx.mochimo.com<br />
<br />
===== Mochimap Visualization For TestNet =====<br />
<br />
TestNet has a dedicated visualizer so that shows you a graphical representation of the network / network health. You can find the TestNet Mochimap at: http://testnet.mochimap.net<br />
<br />
===== Backend API =====<br />
<br />
The TestNet API has the same features and functions as the Main Net API. Please see the [[Mochimo_API|MOCHIMO_API]] page for detailed guidance.<br />
<br />
The Public TestNet API is available at http://testnet-api.mochimo.com:8888<br />
<br />
Here's a quick reference for some of our TestNet API Endpoints:<br />
<br />
{| class="wikitable"<br />
!width="14%"| Endpoint<br />
!width="85%"| Description<br />
|-<br />
| <code>/net/balance/[WOTS]</code><br />
| balance of the address from the network<br />
|-<br />
| <code>/net/resolve/[tag]</code><br />
| resolve the address attached to the tag from the network<br />
|-<br />
| <code>/net/nodes</code><br />
| all network nodes<br />
|-<br />
| <code>/net/chains</code><br />
| all chains/subnetworks<br />
|-<br />
| <code>/net/chain</code><br />
| main chain/subnetwork<br />
|-<br />
|<br />
|<br />
|-<br />
| <code>/bc/balance/[WOTS]</code><br />
| balance of the address from the local blockchain<br />
|-<br />
| <code>/bc/resolve/[tag]</code><br />
| resolve the address attached to the tag from the blockchain<br />
|-<br />
| <code>/bc/block/[block number]</code><br />
| details of the block<br />
|-<br />
| <code>/bc/raw/[block number]</code><br />
| download block<br />
|-<br />
|<br />
|<br />
|-<br />
| <code>/balance/[WOTS]</code><br />
| balance of the address from network and local blockchain<br />
|-<br />
| <code>/resolve/[tag]</code><br />
| resolve the address attached to the tag from network and local blockchain<br />
|-<br />
|<br />
|<br />
|-<br />
| <code>/push</code><br />
| push a transaction to the network. <code>POST {&quot;transaction&quot;: [base64 encoded transaction], &quot;recipients&quot;: [number of nodes to send the transaction to (optional)]}</code><br />
|}</div>NickP05http://www.mochiwiki.com/w/index.php?title=Exchange_Integration&diff=540Exchange Integration2021-03-20T16:20:00Z<p>NickP05: </p>
<hr />
<div>'''Document Title:''' Integrating Mochimo Cryptocurrency w/3rd Party Transaction Systems<br />
<br />
'''Intended Audience:''' Technical Integration Teams for Cryptocurrency Exchanges, Payment Processors, and 2nd Layer Service Providers.\<br />
<br />
'''Summary:''' This document describes Mochimo Addresses, Address Tags, Basic Transaction Creation, API Integration, and using the command-line wallet tools for 3rd party systems and exchange integration.<br />
<br />
'''Author:''' Matt Zweil (stackoverflo)<br />
<br />
'''Last Updated:''' 6 August 2020<br />
<br />
<br />
<br />
== Introduction to Mochimo Addresses ==<br />
Mochimo uses WOTS+ digital signatures in the form of a Public Key “Address” and Secret Key. Mochimo Public Keys are only signed one time, and then never used again. A separate short identifier called an “Address Tag” is bound to the WOTS+ Public Key and moved to a new Public Key each time a Public Key is signed (spent). The actually long-form WOTS+ Public key (2208 Bytes) is usually transparent to senders and receivers, as they just refer to their short address tag to send and receive MCM. The Mochimo wallet keeps a pool of “raw” WOTS+ addresses to move the user’s Address Tag to with each transaction.<br />
Mochimo’s Public Key Addresses have a unique optional field called an “Address Tag”. When you first create the WOTS+ Address/Secret pair, it will be an "untagged" address otherwise referred to as a "raw” WOTS address. The tag field in the address is the last 12 bytes. <br />
<br />
'''Note:''' For an untagged address, the last 12 bytes of the 2208 byte raw WOTS+ Address will be set to the default value of: 0x420000000e00000001000000<br />
<br />
== Introduction to Mochimo "Tags" ==<br />
Mochimo has an on-chain binding between a user’s WOTS+ Public Key, and a short 12-byte field called an "address tag", or just "tag". Tags are globally unique, owned by the user forever, and can only be moved from one WOTS+ address to the next by signing a transaction where the source address owns that 12-byte Tag binding. Mochimo has a unique concept in cryptocurrency called a “Change Address”, which is a required part of any transaction. The “Change Address” is where any unspent coins go, when the users does a partial spend of their wallet. The wallet specifies the new “raw” WOTS+ address in the “Change Address” field, and when the transaction is accepted on the network, the 12-byte tag binding moves to that new address on our blockchain.<br />
Creating the Tag for the first time is called “Registering” as tag, and it involves a slightly different process. The steps to creating an address tag are simple:<br />
<br />
== Creating a New Tag for the First Time ==<br />
• Generate a WOTS Public/Secret Pair (for example using our wallet)<br />
• Generate a Random 12-byte Number<br />
• Confirm that new 12-byte tag is not already in use (not very likely)<br />
o You can use the API endpoint: /net/resolve/[tag]<br />
• Replace the last 12 bytes of any WOTS Public key (0x420000000e00000001000000 by default) with your new 12-byte tag. Note the Mochimo wallet does this automatically for you.<br />
• Register the tag on the network by sending any amount of MCM to it in a transaction with the following form:<br />
o Source Address: Raw WOTS Address #1<br />
o Destination Address: RAW WOTS Address #2<br />
o Change Address: Your Newly Tagged WOTS Address (different from #1 and #2)<br />
o Amount: [At least .000001 MCM aka 1000 satochis]<br />
When we send to a "Change Address" and include our new tag, that tag becomes part of the block chain, and is now "bound" to that WOTS address in the blockchain ledger. <br />
<br />
'''Note:''' It is a requirement that this registration process happens from an untagged WOTS+ address.<br />
The process of creating raw WOTS+ addresses in bulk, as well as the process of creating and registering unique tags in bulk is automated using our Command Line Wallet, and is covered in additional detail later in this document.<br />
<br />
== Introduction to Mochimo Transactions ==<br />
Here is the basic flow of a person-to-person Mochimo transaction. In this example, Alice has an address tag "0x123412341234123412341234" and wants to send MCM to Bob. Her address balance has 10 MCM, and she wants to send Bob 1 MCM.<br />
1. Alice asks Bob for his Mochimo address.<br />
2. Bob provides Alice with a short 12-byte number, for example: 0xB0BB0BB0BB0BB0BB0BB0BB0B<br />
3. Alice enters that tag into her Mojo Wallet and names it: "Bob".<br />
4. Alice clicks "Send" and selects her source tag which she has named "Alice", and selects the destination address "Bob". She enters the send amount of 1 MCM, and clicks Send.<br />
5. Alice’s Mochimo Wallet “resolves” Bob’s tag by asking the network which WOTS+ address it is bound to.<br />
• In the backend, Alice's Mochimo wallet calls the network API with the "/net/resolve" endpoint and passes it the 12-byte tag 0xB0BB0BB0BB0BB0BB0BB0BB0B. The network responds with the full WOTS address (2208 bytes ending in 0xB0BB0BB0BB0BB0BB0BB0BB0B). The wallet will use this 2208 bytes as the Destination Address for the transaction it is preparing.<br />
6. The wallet selects an unused raw WOTS+ address from its local pool of WOTS+ Key/Secret pairs and sets it as the “Change Address” for the transaction.<br />
• The unsent coins (9MCM) will be forwarded to this Change automatically by the network.<br />
7. The wallet creates and signs the transaction using the full WOTS address for Alice’s source, the full WOTS+ address for Bob’s destination, and the full WOTS+ address of the new Change Address.<br />
8. The wallet connects to some network nodes and sends the full transaction. The transaction includes the digital signature of the entire transaction signed with the secret key for Alice's Source WOTS+ Address.<br />
<br />
'''Note:''' When the node receives a transaction with a tagged address, it checks that the tag and the WOTS address binding is correct for all tagged address. If they are, it will process the transaction, otherwise it will reject it.<br />
<br />
=== A Closer Look at the Example Transaction ===<br />
Alice's Mochimo wallet has a pool of available "raw WOTS" Public Key/Secret Key pairs. They have no tag on the end, and instead end with the default of 0x420000000e00000001000000 tag. When it is time for Alice to SEND a transaction, the wallet picks one of those unused raw addresses, and as part of the transaction it MOVES THE TAG, from the old source address to the new Change Address.<br />
So here is what Alice sent to the network:<br />
Tagged Source Address - Alice's full WOTS+ address, ending in 0x123412341234123412341234<br />
Tagged Destination Address - Bob's full WOTS+ address, ending in 0xB0BB0BB0BB0BB0BB0BB0BB0B<br />
Tagged Change Address - Alice's NEW WOTS+ address, ending in 0x123412341234123412341234<br />
Amount: 1000000000 - 1 billion satochis - AKA 1 MCM]<br />
Fee: 500 - Default network fee is 500 satochis<br />
Signature: - The above transaction, signed with the secret key of the Source Address<br />
<br />
The only way to move a tag from one address to another, it to sign a transaction with the private key of the Source Address, where the transaction has a Change Address with the SAME tag. When that happens, whatever balance the Source Address has minus whatever is sent to the Destination Address, will move to the Change Address.<br />
The next time someone wants to send money to Alice's 0x123412341234123412341234 tag, they will send a /net/resolve call and the full WOTS of the "Change Address" from the above transaction will now be returned, because that is what is bound to that Tag on the blockchain.<br />
<br />
== How Exchanges Use Tags ==<br />
=== 1: Create a Pool of Deterministic Addresses ===<br />
An exchange will want a large pool of unused raw WOTS+ addresses to use across all users.<br />
Many exchanges opt to use the command line tool to create a pool of unused WOTS addresses/secrets, and then store them in a database. To use that tool, execute the following command:<br />
java -jar mojo.jar wots --index 0 --count 5000 --mnemonic-words "word1 word2 word3" mywots.json<br />
The above will generate 5000 WOTS/secret pairs from index 0 to 4999 using the mnemonic-words as a determinist seed and store those addresses in the file: mywots.json. You will then store these in a database.<br />
<br />
=== 2: Register Tags on the Network ===<br />
An exchange will purchase a small amount of Mochimo, for example .0001 MCM, and send them to an untagged WOTS address (WOTS-1). They will then generate a pool of 1000 random 12-byte numbers and proceed to check that they are not in use on the network using the /net/resolve/[tag] API endpoint for each tag. For each tag1 to tag1000, the exchange will then have a script that does the following:<br />
<br />
Send <br />
SOURCE: Raw WOTS1 Address<br />
DESTINATION: Raw WOTS2 Address<br />
CHANGE: Tagged WOTS Address Ending in tag1<br />
Amount 1000<br />
Signature<br />
<br />
Wait 1 Block<br />
<br />
Send <br />
SOURCE: Raw WOTS 2 Address<br />
DESTINATION: Raw WOTS 1 Address<br />
CHANGE: Tagged WOTS Address Ending in tag2<br />
Amount 1000<br />
Signature<br />
<br />
Repeat<br />
<br />
Notice that we are sending back and forth between WOTS1 and WOTS2, which means we're signing the same WOTS address multiple times. This is an easy way to register multiple tags. In normal use we would NOT sign the same WOTS address more than once. Tag registration is the only exception. Since we only have .0001 MCM in those addresses, we don't worry about the security implications for this method. There are other ways to do this, but this is the quickest/easiest.<br />
<br />
At the end of this this process, we have 1000 Registered Address Tags in our database that are bound to 1000 of our WOTS Address Pairs.<br />
<br />
=== 3: Assign an Address Tag to Each User Account ===<br />
When a user buys MCM coins for the first time on the exchange, or when they click the "Receive Address" button for first time, the exchange looks in its pool of unused Registered Address Tags, and PERMANENTLY assigns one to the user. From that moment, on the user can send and receive coins from that address tag.<br />
<br />
==== 4: Sending Coins - Create the Transaction File ====<br />
When the user wants to send coins off the exchange, the exchange collects the "destination tag" from the user, and then does an API call to find the full WOTS address: /net/resolve/[tag]. The exchange then creates a transaction file using the CLI:<br />
<br />
java -jar mojo.jar sign \<br />
--source-wots USERS-FULL-WOTS-ADDRESS-WITH-TAG \<br />
--source-secret SECRETKEY-FOR-USERS-WOTS-ADDRESS \<br />
--destination-wots FULL-ADDRESS-RETURNED-BY-NET-RESOLVE-API \<br />
--change-wots NEW-UNUSED-WOTS-ADDRESS-FROM-DATABASE-ADDING-USERS-TAG \<br />
--offline \<br />
--source-balance CURRENT_BALANCE AMOUNT_TO_SEND \<br />
FILENAME<br />
<br />
Call the above jar file and pass it the user's source address and secret, select an unused WOTS address from the pool of 5000 raw addresses in your database. Mark it as used. Add the user's tag to the last 12 bytes to create the "change address" for the transaction. Add the destination address that was resolved by the API and specify that you want to generate a transaction file offline. Pass it the source address's balance and the amount you want to send. Finally include the file name you want the BASE64 encoded transaction stored in.<br />
<br />
==== 5: Sending Coins - Use the API to Send the TX ====<br />
Now complete an API call (in this example we show the URL for the Mochimo Public API, but you can maintain your own - and we recommend that you do.) To post that transaction to 5 random nodes on the network using the "/push" API endpoint complete the TX as follows:<br />
http://api.mochimo.org:8888/push<br />
POST {"transaction": [base64 encoded transaction from file], "recipients": 5}<br />
With the above approach, the exchange marks the old address as "used" in the database, and marks the new "change address" with the moved tag as the "current" address. The user's address tag never changes.</div>NickP05http://www.mochiwiki.com/w/index.php?title=MIP-0004&diff=472MIP-00042020-11-23T12:47:47Z<p>NickP05: </p>
<hr />
<div>= MIP-0004 - TAG settings =<br />
Proposal written by [[User:NickP05|NickP05]]<br />
== Disclaimer ==<br />
I'm not the first to have this idea, but I think it's the time to write it up.<br />
== Sponsor(s) ==<br />
Waiting for one<br />
<br />
== MIP summary ==<br />
The hard fork consists in adding some constraints called "settings" to a specific TAG. These setting will change the TAG freedom to perform validated (by the nodes) payments. <br />
<br />
= The proposal =<br />
<br />
== Hard Fork Required ==<br />
Yes.<br />
<br />
== Theory Overview ==<br />
Adding some settings to a TAG. The settings are constrains that limits the ability to perform transactions. The settings should be validated as a special transaction and they will be working after the block solves. Every setting has a<br />
* reference period<br />
* renewal period<br />
Let's explain them together..<br />
The reference period is a number. This number references to after how many blocks the settings values have to be reset.<br />
The renewal period is a number that refers after how many reference periods the reference period should stop to renew, and as consequence the setting should be disabled (destroyed from the ledger).<br />
<br />
=== spending variable types ===<br />
As I said before, the reference period refers to a time in which there is a variable to change. Well, that variable is defined in 2 types<br />
* maximum_spendable --> this type of variable sets a maximum amount of MCM, as satoshi, that can be spent in the reference period into payments to the <i>affair</i>.<br />
* reserved_balance --> this type of variable sets a minimum amount of MCM, as satoshi, in the TAG to reserve for payments to the <i>affair</I>.<br />
<br />
=== the spending ===<br />
The variable I am referring to will be called <I>spending</I>. And as a transaction is made to an affair contained in a TAG setting, the spending_state variable will decrease by the amount spent.<br />
If a transaction will be setting the spending_state below 0, the transaction should be refused by the node and not accepted in the blockchain.<br />
At every reference period renewal, the spending_state will be reset to the original spending state stated in the setting.<br />
<br />
=== setting modify transaction ===<br />
Every setting is not unmovable. The settings can't be changed inside a reference period, but can be changed from a reference period to the other. <br />
A setting change should be approved (signed) by the owner and all the co owners of the settings as a special transaction. The new setting should be identical in reference_period, renewal_period and the<br />
variable_type as the previously setting, but it can change the <I>spending</I> variable. As the setting is updated, the renewal_period_state should not be forced to change.<br />
<br />
=== owners and co-owners ===<br />
I mentioned before the owners and the co-owners. They all basically have the same rights. The owner is a special type of co-owner: it has the ability to renew or not renew the setting as the<br />
renewal_period_state reaches 0. The co-owners have the ability to refuse a proposed change as a setting change transaction should be signed by all co-owners and the owner mentioned in the setting.<br />
The owner of a setting is not necessarily the TAG owner.</div>NickP05http://www.mochiwiki.com/w/index.php?title=MIP-0004&diff=471MIP-00042020-11-23T12:32:37Z<p>NickP05: </p>
<hr />
<div>= MIP-0004 - TAG settings =<br />
Proposal written by [[User:NickP05|NickP05]]<br />
== Disclaimer ==<br />
I'm not the first to have this idea, but I think it's the time to write it up.<br />
== Sponsor(s) ==<br />
Waiting for one<br />
<br />
== MIP summary ==<br />
The hard fork consists in adding some constraints called "settings" to a specific TAG. These setting will change the TAG freedom to perform validated (by the nodes) payments. <br />
<br />
= The proposal =<br />
<br />
== Hard Fork Required ==<br />
Yes.<br />
<br />
== Theory Overview ==<br />
Adding some settings to a TAG. The settings are constrains that limits the ability to perform transactions. The settings should be validated as a special transaction and they will be working after the block solves. Every setting has a<br />
* reference period<br />
* renewal period<br />
Let's explain them together..<br />
The reference period is a number. This number references to after how many blocks the settings values have to be reset.<br />
The renewal period is a number that refers after how many reference periods the reference period should stop to renew, and as consequence the setting should be disabled (destroyed from the ledger).<br />
<br />
=== spending variable types ===<br />
As I said before, the reference period refers to a time in which there is a variable to change. Well, that variable is defined in 2 types<br />
* maximum_spendable --> this type of variable sets a maximum amount of MCM, as satoshi, that can be spent in the reference period into payments to the <i>affair</i>.<br />
* reserved_balance --> this type of variable sets a minimum amount of MCM, as satoshi, in the TAG to reserve for payments to the <i>affair</I>.<br />
<br />
=== the spending ===<br />
The variable I am referring to will be called <I>spending</I>. And as a transaction is made to an affair contained in a TAG setting, the spending_state variable will decrease by the amount spent.<br />
If a transaction will be setting the spending_state below 0, the transaction should be refused by the node and not accepted in the blockchain.<br />
At every reference period renewal, the spending_state will be reset to the original spending state stated in the setting.<br />
<br />
=== setting modify transaction ===<br />
Every setting is not unmovable. The settings can't be changed inside a reference period, but can be changed from a reference period to the other. <br />
A setting change should be approved (signed) by the owner and all the co owners of the settings as a special transaction. The new setting should be identical in reference_period, renewal_period and the<br />
variable_type as the previously setting, but it can change the <I>spending</I> variable. As the setting is updated, the renewal_period_state should not be forced to change.<br />
<br />
=== owners and co-owners ===<br />
I mentioned before the owners and the co-owners. They all basically have the same rights. The owner is a special type of co-owner: it has the ability to renew or not renew the setting as the<br />
renewal_period_state reaches 0. The co-owners have the ability to refuse a proposed change as a setting change should be signed by all co-owners and the owner mentioned in the setting.<br />
The owner of a setting is not necessarily the TAG owner.<br />
<br />
== Technical Details ==<br />
* In the Ledger Entry Struct, add an 8-byte Field "address_origin_block" containing the block height in which an address is first added to the Ledger.<br />
* In the Block Header Struct, add an 8-byte value "recovery_total" to aggregate all recovered "lost coins" to be added to the end of the mining period as mineable coins.<br />
* In the definitions header, add the Global definition "MAX_ADDRESS_LIFESPAN" and set it equal to 8388608 (2^23 blocks).<br />
* Add 8-byte global variable Recovered_coins<br />
<br />
* In the node logic, add to the Block Reward algorithm a check to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, set the mining reward for the current block to +=1 MCM.<br />
* In the node logic, add an entry to the update() function to determine if the "recovery_total" variable is is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, debit 1 from the Recovered_coins global variable at the end of the update() routine.<br />
* In the node logic, add an entry to the bval() routine to confirm that the Block Header "recovery_total" matches the local global Recovered_coins.<br />
** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the bval() routine to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.<br />
*** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the update() function to scan the local ledger and find any ledger entry for which the current_block - address_origin_block is greater than or equal to MAX_ADDRESS_LIFESPAN.<br />
** If the above is true, increment the global Recovered_coins variable with the Amount from the address.<br />
** If the above is true, remove the Ledger entry for that address.</div>NickP05http://www.mochiwiki.com/w/index.php?title=MIP-0004&diff=470MIP-00042020-11-23T12:30:11Z<p>NickP05: </p>
<hr />
<div>= MIP-0004 - TAG settings =<br />
Proposal written by [[User:NickP05|NickP05]]<br />
== Disclaimer ==<br />
I'm not the first to have this idea, but I think it's the time to write it up.<br />
== Sponsor(s) ==<br />
Waiting for one<br />
<br />
== MIP summary ==<br />
The hard fork consists in adding some constraints called "settings" to a specific TAG. These setting will change the TAG freedom to perform validated (by the nodes) payments. <br />
<br />
= The proposal =<br />
<br />
== Hard Fork Required ==<br />
Yes.<br />
<br />
== Theory Overview ==<br />
Adding some settings to a TAG. The settings are constrains that limits the ability to perform transactions. The settings should be validated as a special transaction and they will be working after the block solves. Every setting has a<br />
* reference period<br />
* renewal period<br />
Let's explain them together..<br />
The reference period is a number. This number references to after how many blocks the settings values have to be reset.<br />
The renewal period is a number that refers after how many reference periods the reference period should stop to renew, and as consequence the setting should be disabled (destroyed from the ledger).<br />
<br />
As I said before, the reference period refers to a time in which there is a variable to change. Well, that variable is defined in 2 types<br />
* maximum_spendable --> this type of variable sets a maximum amount of MCM, as satoshi, that can be spent in the reference period into payments to the <i>affair</i>.<br />
* reserved_balance --> this type of variable sets a minimum amount of MCM, as satoshi, in the TAG to reserve for payments to the <i>affair</i>.<br />
<br><br />
The variable I am referring to will be called <I>spending</I>. And as a transaction is made to an affair contained in a TAG setting, the spending_state variable will decrease by the amount spent.<br />
If a transaction will be setting the spending_state below 0, the transaction should be refused by the node and not accepted in the blockchain.<br />
At every reference period renewal, the spending_state will be reset to the original spending state stated in the setting.<br />
<br><br><br />
Every setting is not unmovable. The settings can't be changed inside a reference period, but can be changed from a reference period to the other. <br />
A setting change should be approved (signed) by the owner and all the co owners of the settings as a special transaction. The new setting should be identical in reference_period, renewal_period and the<br />
variable_type as the previously setting, but it can change the <I>spending</I> variable. As the setting is updated, the renewal_period_state should not be forced to change.<br />
<br />
=== owners and co-owners ====<br />
I mentioned before the owners and the co-owners. They all basically have the same rights. The owner is a special type of co-owner: it has the ability to renew or not renew the setting as the<br />
renewal_period_state reaches 0. The co-owners have the ability to refuse a proposed change as a setting change should be signed by all co-owners and the owner mentioned in the setting.<br />
The owner of a setting is not necessarily the TAG owner.<br />
<br />
== Technical Details ==<br />
* In the Ledger Entry Struct, add an 8-byte Field "address_origin_block" containing the block height in which an address is first added to the Ledger.<br />
* In the Block Header Struct, add an 8-byte value "recovery_total" to aggregate all recovered "lost coins" to be added to the end of the mining period as mineable coins.<br />
* In the definitions header, add the Global definition "MAX_ADDRESS_LIFESPAN" and set it equal to 8388608 (2^23 blocks).<br />
* Add 8-byte global variable Recovered_coins<br />
<br />
* In the node logic, add to the Block Reward algorithm a check to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, set the mining reward for the current block to +=1 MCM.<br />
* In the node logic, add an entry to the update() function to determine if the "recovery_total" variable is is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, debit 1 from the Recovered_coins global variable at the end of the update() routine.<br />
* In the node logic, add an entry to the bval() routine to confirm that the Block Header "recovery_total" matches the local global Recovered_coins.<br />
** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the bval() routine to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.<br />
*** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the update() function to scan the local ledger and find any ledger entry for which the current_block - address_origin_block is greater than or equal to MAX_ADDRESS_LIFESPAN.<br />
** If the above is true, increment the global Recovered_coins variable with the Amount from the address.<br />
** If the above is true, remove the Ledger entry for that address.</div>NickP05http://www.mochiwiki.com/w/index.php?title=MIP-0004&diff=469MIP-00042020-11-23T12:23:36Z<p>NickP05: </p>
<hr />
<div>= MIP-0004 - TAG settings =<br />
Proposal written by [[User:NickP05|NickP05]]<br />
== Disclaimer ==<br />
I'm not the first to have this idea, but I think it's the time to write it up.<br />
== Sponsor(s) ==<br />
Waiting for one<br />
<br />
== MIP summary ==<br />
The hard fork consists in adding some constraints called "settings" to a specific TAG. These setting will change the TAG freedom to perform validated (by the nodes) payments. <br />
<br />
= The proposal =<br />
<br />
== Hard Fork Required ==<br />
Yes.<br />
<br />
== Theory Overview ==<br />
Adding some settings to a TAG. The settings are constrains that limits the ability to perform transactions. The settings should be validated as a special transaction and they will be working after the block solves. Every setting has a<br />
* reference period<br />
* renewal period<br />
Let's explain them together..<br />
The reference period is a number. This number references to after how many blocks the settings values have to be reset.<br />
The renewal period is a number that refers after how many reference periods the reference period should stop to renew, and as consequence the setting should be disabled (destroyed from the ledger).<br />
<br />
As I said before, the reference period refers to a time in which there is a variable to change. Well, that variable is defined in 2 types<br />
* maximum_spendable --> this type of variable sets a maximum amount of MCM, as satoshi, that can be spent in the reference period into payments to the <i>affair</i>.<br />
* reserved_balance --> this type of variable sets a minimum amount of MCM, as satoshi, in the TAG to reserve for payments to the <i>affair</i>.<br />
<br><br><br />
The variable I am referring to will be called <I>spending</I>. And as a transaction is made to an affair contained in a TAG setting, the spending_state variable will decrease by the amount spent.<br />
If a transaction will be setting the spending_state below 0, the transaction should be refused by the node and not accepted in the blockchain.<br />
At every reference period renewal, the spending_state will be reset to the original spending state stated in the setting.<br />
<br><br><br />
Every setting is not unmovable. The settings can't be changed inside a reference period, but can be changed from a reference period to the other. <br />
A setting change should be approved (signed) by the owner and all the co owners of the settings as a special transaction. The new setting should be identical in reference_period, renewal_period and the<br />
variable_type as the previously setting, but it can change the <I>spending</I> variable. As the setting is updated, the renewal_period_state should not be forced to change.<br />
<br><br><br />
<br />
== Technical Details ==<br />
* In the Ledger Entry Struct, add an 8-byte Field "address_origin_block" containing the block height in which an address is first added to the Ledger.<br />
* In the Block Header Struct, add an 8-byte value "recovery_total" to aggregate all recovered "lost coins" to be added to the end of the mining period as mineable coins.<br />
* In the definitions header, add the Global definition "MAX_ADDRESS_LIFESPAN" and set it equal to 8388608 (2^23 blocks).<br />
* Add 8-byte global variable Recovered_coins<br />
<br />
* In the node logic, add to the Block Reward algorithm a check to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, set the mining reward for the current block to +=1 MCM.<br />
* In the node logic, add an entry to the update() function to determine if the "recovery_total" variable is is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, debit 1 from the Recovered_coins global variable at the end of the update() routine.<br />
* In the node logic, add an entry to the bval() routine to confirm that the Block Header "recovery_total" matches the local global Recovered_coins.<br />
** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the bval() routine to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.<br />
*** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the update() function to scan the local ledger and find any ledger entry for which the current_block - address_origin_block is greater than or equal to MAX_ADDRESS_LIFESPAN.<br />
** If the above is true, increment the global Recovered_coins variable with the Amount from the address.<br />
** If the above is true, remove the Ledger entry for that address.</div>NickP05http://www.mochiwiki.com/w/index.php?title=MIP-0004&diff=468MIP-00042020-11-23T12:23:03Z<p>NickP05: </p>
<hr />
<div>= MIP-0004 - TAG settings =<br />
Proposal written by [[User:NickP05|NickP05]]<br />
== Disclaimer ==<br />
I'm not the first to have this idea, but I think it's the time to write it up.<br />
== Sponsor(s) ==<br />
Waiting for one<br />
<br />
== MIP summary ==<br />
The hard fork consists in adding some constraints called "settings" to a specific TAG. These setting will change the TAG freedom to perform validated (by the nodes) payments. <br />
<br />
= The proposal =<br />
<br />
== Hard Fork Required ==<br />
Yes.<br />
<br />
== Theory Overview ==<br />
Adding some settings to a TAG. The settings are constrains that limits the ability to perform transactions. The settings should be validated as a special transaction and they will be working after the block solves. Every setting has a<br />
* reference period<br />
* renewal period<br />
Let's explain them together..<br />
The reference period is a number. This number references to after how many blocks the settings values have to be reset.<br />
The renewal period is a number that refers after how many reference periods the reference period should stop to renew, and as consequence the setting should be disabled (destroyed from the ledger).<br />
<br />
As I said before, the reference period refers to a time in which there is a variable to change. Well, that variable is defined in 2 types<br />
* maximum_spendable --> this type of variable sets a maximum amount of MCM, as satoshi, that can be spent in the reference period into payments to the <i>affair</i>.<br />
* reserved_balance --> this type of variable sets a minimum amount of MCM, as satoshi, in the TAG to reserve for payments to the <i>affair</i>.<br />
<br />
The variable I am referring to will be called <I>spending</I>. And as a transaction is made to an affair contained in a TAG setting, the spending_state variable will decrease by the amount spent.<br />
If a transaction will be setting the spending_state below 0, the transaction should be refused by the node and not accepted in the blockchain.<br />
At every reference period renewal, the spending_state will be reset to the original spending state stated in the setting.<br />
<br><br />
Every setting is not unmovable. The settings can't be changed inside a reference period, but can be changed from a reference period to the other. <br />
A setting change should be approved (signed) by the owner and all the co owners of the settings as a special transaction. The new setting should be identical in reference_period, renewal_period and the<br />
variable_type as the previously setting, but it can change the <I>spending</I> variable. As the setting is updated, the renewal_period_state should not be forced to change.<br />
<br><br />
<br />
== Technical Details ==<br />
* In the Ledger Entry Struct, add an 8-byte Field "address_origin_block" containing the block height in which an address is first added to the Ledger.<br />
* In the Block Header Struct, add an 8-byte value "recovery_total" to aggregate all recovered "lost coins" to be added to the end of the mining period as mineable coins.<br />
* In the definitions header, add the Global definition "MAX_ADDRESS_LIFESPAN" and set it equal to 8388608 (2^23 blocks).<br />
* Add 8-byte global variable Recovered_coins<br />
<br />
* In the node logic, add to the Block Reward algorithm a check to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, set the mining reward for the current block to +=1 MCM.<br />
* In the node logic, add an entry to the update() function to determine if the "recovery_total" variable is is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, debit 1 from the Recovered_coins global variable at the end of the update() routine.<br />
* In the node logic, add an entry to the bval() routine to confirm that the Block Header "recovery_total" matches the local global Recovered_coins.<br />
** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the bval() routine to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.<br />
*** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the update() function to scan the local ledger and find any ledger entry for which the current_block - address_origin_block is greater than or equal to MAX_ADDRESS_LIFESPAN.<br />
** If the above is true, increment the global Recovered_coins variable with the Amount from the address.<br />
** If the above is true, remove the Ledger entry for that address.</div>NickP05http://www.mochiwiki.com/w/index.php?title=MIP-0004&diff=467MIP-00042020-11-23T11:57:15Z<p>NickP05: </p>
<hr />
<div>= MIP-0004 - TAG settings =<br />
Proposal written by [[User:NickP05|NickP05]]<br />
== Disclaimer ==<br />
I'm not the first to have this idea, but I think it's the time to write it up.<br />
== Sponsor(s) ==<br />
Waiting for one<br />
<br />
== MIP summary ==<br />
The hard fork consists in adding some constraints called "settings" to a specific TAG. These setting will change the TAG freedom to perform validated (by the nodes) payments. <br />
<br />
= The proposal =<br />
<br />
== Hard Fork Required ==<br />
Yes.<br />
<br />
== Overview ==<br />
Adding some settings to a TAG. The settings are constrains that limits the ability to perform transactions. The settings should be validated as a special transaction and they will be working after the block solves. Every setting has a<br />
* reference period<br />
* renewal period<br />
Let's explain them together..<br />
The reference period is a number. This number references to after how many blocks the settings values have to be reset.<br />
The renewal period is a number that refers after how many reference periods the reference period should stop to renew, and as consequence the setting should be disabled (destroyed from the ledger).<br />
<br />
As I said before, the reference period refers to a time in which there is a variable to change. Well, that variable is defined in 2 types<br />
* maximum_spendable --> this type of variable sets a maximum amount of MCM, as satoshi, that can be spent in the reference period into payments to the <i>affair</i>.<br />
* reserved_balance --> this type of variable sets a minimum amount of MCM, as satoshi, in the TAG to reserve for payments to the <i>affair</i>.<br />
<br />
The variable I am referring to will be called <I>spending</I>. And as a transaction is made to an affair contained in a TAG setting, the spending_state variable will decrease by the amount spent.<br />
If a transaction will be setting the spending_state below 0, the transaction should be refused by the node and not accepted in the blockchain.<br />
At every reference period renewal, the spending_state will be reset to the original spending stated in the setting<br />
<br />
<br />
<br />
== Technical Details ==<br />
* In the Ledger Entry Struct, add an 8-byte Field "address_origin_block" containing the block height in which an address is first added to the Ledger.<br />
* In the Block Header Struct, add an 8-byte value "recovery_total" to aggregate all recovered "lost coins" to be added to the end of the mining period as mineable coins.<br />
* In the definitions header, add the Global definition "MAX_ADDRESS_LIFESPAN" and set it equal to 8388608 (2^23 blocks).<br />
* Add 8-byte global variable Recovered_coins<br />
<br />
* In the node logic, add to the Block Reward algorithm a check to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, set the mining reward for the current block to +=1 MCM.<br />
* In the node logic, add an entry to the update() function to determine if the "recovery_total" variable is is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, debit 1 from the Recovered_coins global variable at the end of the update() routine.<br />
* In the node logic, add an entry to the bval() routine to confirm that the Block Header "recovery_total" matches the local global Recovered_coins.<br />
** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the bval() routine to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.<br />
*** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the update() function to scan the local ledger and find any ledger entry for which the current_block - address_origin_block is greater than or equal to MAX_ADDRESS_LIFESPAN.<br />
** If the above is true, increment the global Recovered_coins variable with the Amount from the address.<br />
** If the above is true, remove the Ledger entry for that address.</div>NickP05http://www.mochiwiki.com/w/index.php?title=MIP-0004&diff=466MIP-00042020-11-23T11:56:18Z<p>NickP05: </p>
<hr />
<div>= MIP-0004 - TAG settings =<br />
Proposal written by [[User:NickP05|NickP05]]<br />
== Disclaimer ==<br />
I'm not the first to have this idea, but I think it's the time to write it up.<br />
== Sponsor(s) ==<br />
Waiting for one<br />
<br />
== MIP summary ==<br />
The hard fork consists in adding some constraints called "settings" to a specific TAG. These setting will change the TAG freedom to perform validated (by the nodes) payments. <br />
<br />
== Hard Fork Required ==<br />
Yes.<br />
<br />
== The proposal ==<br />
Adding some settings to a TAG. The settings are constrains that limits the ability to perform transactions. The settings should be validated as a special transaction and they will be working after the block solves. Every setting has a<br />
* reference period<br />
* renewal period<br />
Let's explain them together..<br />
The reference period is a number. This number references to after how many blocks the settings values have to be reset.<br />
The renewal period is a number that refers after how many reference periods the reference period should stop to renew, and as consequence the setting should be disabled (destroyed from the ledger).<br />
<br />
As I said before, the reference period refers to a time in which there is a variable to change. Well, that variable is defined in 2 types<br />
* maximum_spendable --> this type of variable sets a maximum amount of MCM, as satoshi, that can be spent in the reference period into payments to the <i>affair</i>.<br />
* reserved_balance --> this type of variable sets a minimum amount of MCM, as satoshi, in the TAG to reserve for payments to the <i>affair</i>.<br />
<br />
The variable I am referring to will be called <I>spending</I>. And as a transaction is made to an affair contained in a TAG setting, the spending_state variable will decrease by the amount spent.<br />
If a transaction will be setting the spending_state below 0, the transaction should be refused by the node and not accepted in the blockchain.<br />
At every reference period renewal, the spending_state will be reset to the original spending stated in the setting<br />
<br />
<br />
<br />
== Technical Details ==<br />
* In the Ledger Entry Struct, add an 8-byte Field "address_origin_block" containing the block height in which an address is first added to the Ledger.<br />
* In the Block Header Struct, add an 8-byte value "recovery_total" to aggregate all recovered "lost coins" to be added to the end of the mining period as mineable coins.<br />
* In the definitions header, add the Global definition "MAX_ADDRESS_LIFESPAN" and set it equal to 8388608 (2^23 blocks).<br />
* Add 8-byte global variable Recovered_coins<br />
<br />
* In the node logic, add to the Block Reward algorithm a check to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, set the mining reward for the current block to +=1 MCM.<br />
* In the node logic, add an entry to the update() function to determine if the "recovery_total" variable is is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, debit 1 from the Recovered_coins global variable at the end of the update() routine.<br />
* In the node logic, add an entry to the bval() routine to confirm that the Block Header "recovery_total" matches the local global Recovered_coins.<br />
** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the bval() routine to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.<br />
*** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the update() function to scan the local ledger and find any ledger entry for which the current_block - address_origin_block is greater than or equal to MAX_ADDRESS_LIFESPAN.<br />
** If the above is true, increment the global Recovered_coins variable with the Amount from the address.<br />
** If the above is true, remove the Ledger entry for that address.</div>NickP05http://www.mochiwiki.com/w/index.php?title=MIP-0004&diff=465MIP-00042020-11-23T11:55:51Z<p>NickP05: </p>
<hr />
<div>= MIP-0004 - TAG settings =<br />
Proposal written by [[User:NickP05|NickP05]]<br />
= Disclaimer =<br />
I'm not the first to have this idea, but I think it's the time to write it up.<br />
== Sponsor(s) ==<br />
Waiting for one<br />
<br />
== MIP summary ==<br />
The hard fork consists in adding some constraints called "settings" to a specific TAG. These setting will change the TAG freedom to perform validated (by the nodes) payments. <br />
<br />
== Hard Fork Required ==<br />
Yes.<br />
<br />
== The proposal ==<br />
Adding some settings to a TAG. The settings are constrains that limits the ability to perform transactions. The settings should be validated as a special transaction and they will be working after the block solves. Every setting has a<br />
* reference period<br />
* renewal period<br />
Let's explain them together..<br />
The reference period is a number. This number references to after how many blocks the settings values have to be reset.<br />
The renewal period is a number that refers after how many reference periods the reference period should stop to renew, and as consequence the setting should be disabled (destroyed from the ledger).<br />
<br />
As I said before, the reference period refers to a time in which there is a variable to change. Well, that variable is defined in 2 types<br />
* maximum_spendable --> this type of variable sets a maximum amount of MCM, as satoshi, that can be spent in the reference period into payments to the <i>affair</i>.<br />
* reserved_balance --> this type of variable sets a minimum amount of MCM, as satoshi, in the TAG to reserve for payments to the <i>affair</i>.<br />
<br />
The variable I am referring to will be called <I>spending</I>. And as a transaction is made to an affair contained in a TAG setting, the spending_state variable will decrease by the amount spent.<br />
If a transaction will be setting the spending_state below 0, the transaction should be refused by the node and not accepted in the blockchain.<br />
At every reference period renewal, the spending_state will be reset to the original spending stated in the setting<br />
<br />
<br />
<br />
== Technical Details ==<br />
* In the Ledger Entry Struct, add an 8-byte Field "address_origin_block" containing the block height in which an address is first added to the Ledger.<br />
* In the Block Header Struct, add an 8-byte value "recovery_total" to aggregate all recovered "lost coins" to be added to the end of the mining period as mineable coins.<br />
* In the definitions header, add the Global definition "MAX_ADDRESS_LIFESPAN" and set it equal to 8388608 (2^23 blocks).<br />
* Add 8-byte global variable Recovered_coins<br />
<br />
* In the node logic, add to the Block Reward algorithm a check to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, set the mining reward for the current block to +=1 MCM.<br />
* In the node logic, add an entry to the update() function to determine if the "recovery_total" variable is is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, debit 1 from the Recovered_coins global variable at the end of the update() routine.<br />
* In the node logic, add an entry to the bval() routine to confirm that the Block Header "recovery_total" matches the local global Recovered_coins.<br />
** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the bval() routine to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.<br />
*** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the update() function to scan the local ledger and find any ledger entry for which the current_block - address_origin_block is greater than or equal to MAX_ADDRESS_LIFESPAN.<br />
** If the above is true, increment the global Recovered_coins variable with the Amount from the address.<br />
** If the above is true, remove the Ledger entry for that address.</div>NickP05http://www.mochiwiki.com/w/index.php?title=MIP-0004&diff=464MIP-00042020-11-23T11:39:41Z<p>NickP05: </p>
<hr />
<div>= MIP-0004 - TAG settings =<br />
Proposal written by [[User:NickP05|NickP05]]<br />
= Disclaimer =<br />
I'm not the first to have this idea, but I think it's the time to write it up.<br />
== Sponsor(s) ==<br />
Waiting for one<br />
<br />
== MIP summary ==<br />
The hard fork consists in adding some constraints called "settings" to a specific TAG. These setting will change the TAG freedom to perform validated (by the nodes) payments. <br />
<br />
== Hard Fork Required ==<br />
Yes.<br />
<br />
== The proposal ==<br />
Adding some settings to a TAG. The settings are constrains that limits the ability to perform transactions. The settings should be validated as a special transaction and they will be working after the block solves. Every setting has a<br />
* reference period<br />
* renewal period<br />
Let's explain them together..<br />
The reference period is a number. This number references to after how many blocks the settings values have to be reset.<br />
The renewal period is a number that refers after how many reference periods the setting should be disabled.<br />
<br />
As I said before, the reference period refers to a time in which there is a variable to change. Well, that variable is defined in 4 types<br />
* maximum_spendable -> this type of variable sets a maximum amount of MCM, as satoshi, that can be spent in the reference period into payments to the <i>affair</i>.<br />
* <br />
<br />
== Technical Details ==<br />
* In the Ledger Entry Struct, add an 8-byte Field "address_origin_block" containing the block height in which an address is first added to the Ledger.<br />
* In the Block Header Struct, add an 8-byte value "recovery_total" to aggregate all recovered "lost coins" to be added to the end of the mining period as mineable coins.<br />
* In the definitions header, add the Global definition "MAX_ADDRESS_LIFESPAN" and set it equal to 8388608 (2^23 blocks).<br />
* Add 8-byte global variable Recovered_coins<br />
<br />
* In the node logic, add to the Block Reward algorithm a check to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, set the mining reward for the current block to +=1 MCM.<br />
* In the node logic, add an entry to the update() function to determine if the "recovery_total" variable is is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, debit 1 from the Recovered_coins global variable at the end of the update() routine.<br />
* In the node logic, add an entry to the bval() routine to confirm that the Block Header "recovery_total" matches the local global Recovered_coins.<br />
** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the bval() routine to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.<br />
*** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the update() function to scan the local ledger and find any ledger entry for which the current_block - address_origin_block is greater than or equal to MAX_ADDRESS_LIFESPAN.<br />
** If the above is true, increment the global Recovered_coins variable with the Amount from the address.<br />
** If the above is true, remove the Ledger entry for that address.</div>NickP05http://www.mochiwiki.com/w/index.php?title=MIP-0004&diff=463MIP-00042020-11-23T11:19:24Z<p>NickP05: Created page with "= MIP-0004 - TAG settings = Proposal written by NickP05 = Disclaimer = I'm not the first to have this idea, but I think it's the time to write it up. == Spons..."</p>
<hr />
<div>= MIP-0004 - TAG settings =<br />
Proposal written by [[User:NickP05|NickP05]]<br />
= Disclaimer =<br />
I'm not the first to have this idea, but I think it's the time to write it up.<br />
== Sponsor(s) ==<br />
Waiting for one<br />
<br />
== MIP summary ==<br />
The hard fork consists in adding some constraints called "settings" to a specific TAG. These setting will change the TAG freedom to perform validated (by the nodes) payments. <br />
<br />
== Hard Fork Required ==<br />
Yes.<br />
<br />
== Technical Details ==<br />
* In the Ledger Entry Struct, add an 8-byte Field "address_origin_block" containing the block height in which an address is first added to the Ledger.<br />
* In the Block Header Struct, add an 8-byte value "recovery_total" to aggregate all recovered "lost coins" to be added to the end of the mining period as mineable coins.<br />
* In the definitions header, add the Global definition "MAX_ADDRESS_LIFESPAN" and set it equal to 8388608 (2^23 blocks).<br />
* Add 8-byte global variable Recovered_coins<br />
<br />
* In the node logic, add to the Block Reward algorithm a check to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, set the mining reward for the current block to +=1 MCM.<br />
* In the node logic, add an entry to the update() function to determine if the "recovery_total" variable is is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, debit 1 from the Recovered_coins global variable at the end of the update() routine.<br />
* In the node logic, add an entry to the bval() routine to confirm that the Block Header "recovery_total" matches the local global Recovered_coins.<br />
** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the bval() routine to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.<br />
** If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.<br />
*** If the above is false, the block fails validation.<br />
* In the node logic, add an entry to the update() function to scan the local ledger and find any ledger entry for which the current_block - address_origin_block is greater than or equal to MAX_ADDRESS_LIFESPAN.<br />
** If the above is true, increment the global Recovered_coins variable with the Amount from the address.<br />
** If the above is true, remove the Ledger entry for that address.</div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=415Payment system2020-10-04T08:49:29Z<p>NickP05: </p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
|'''Fixed fee'''<br />
|0.0000005MCM<br />
|-<br />
|'''Average transaction time'''<br />
|6 minutes (average time to solve a block)<br />
|}<br />
<br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, gets from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this: [https://discord.com/channels/460867662977695765/746628843321950240/762213788198895639 Block 210781 on Mochimo Discord]<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b...<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24...<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be...<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre><br />
<i>The WOTS were truncated down</i><br><br />
As you can see there's the <i>Change adress</i>, the new sender's WOTS and there's also the <i>Change</i>, the new sender's balance.<br><br><br />
<br />
Every transaction has a <b>fixed fee of 0,0000005 Mochimos</b>. The fee could change in future.<br />
<br><br><br />
After a transaction is sent to the network, the sender's account will be blocked from making other transactions until the transactions block is mined.</div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=414Payment system2020-10-04T08:48:57Z<p>NickP05: </p>
<hr />
<div>'''Fixed fee:''' 0.0000005MCM <br><br />
'''Average transaction time''': 6 minutes (average time to solve a block)<br><br />
{| class="wikitable"<br />
|+datas<br />
|-<br />
|'''Fixed fee'''<br />
|0.0000005MCM<br />
|-<br />
|'''Average transaction time'''<br />
|6 minutes (average time to solve a block)<br />
|}<br />
<br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, gets from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this: [https://discord.com/channels/460867662977695765/746628843321950240/762213788198895639 Block 210781 on Mochimo Discord]<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b...<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24...<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be...<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre><br />
<i>The WOTS were truncated down</i><br><br />
As you can see there's the <i>Change adress</i>, the new sender's WOTS and there's also the <i>Change</i>, the new sender's balance.<br><br><br />
<br />
Every transaction has a <b>fixed fee of 0,0000005 Mochimos</b>. The fee could change in future.<br />
<br><br><br />
After a transaction is sent to the network, the sender's account will be blocked from making other transactions until the transactions block is mined.</div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=413Payment system2020-10-04T08:47:03Z<p>NickP05: </p>
<hr />
<div>'''Fixed fee:''' 0.0000005MCM <br><br />
'''Average transaction time''': 6 minutes (average time to solve a block)<br><br />
<br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, gets from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this: [https://discord.com/channels/460867662977695765/746628843321950240/762213788198895639 Block 210781 on Mochimo Discord]<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b...<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24...<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be...<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre><br />
<i>The WOTS were truncated down</i><br><br />
As you can see there's the <i>Change adress</i>, the new sender's WOTS and there's also the <i>Change</i>, the new sender's balance.<br><br><br />
<br />
Every transaction has a <b>fixed fee of 0,0000005 Mochimos</b>. The fee could change in future.<br />
<br><br><br />
After a transaction is sent to the network, the sender's account will be blocked from making other transactions until the transactions block is mined.</div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=412Payment system2020-10-04T08:45:02Z<p>NickP05: </p>
<hr />
<div>'''Fixed fee: 0.0000005MCM'''<br />
'''Average transaction time: 6 minutes (average time to solve a block)'''<br />
<br />
<br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, gets from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this: [https://discord.com/channels/460867662977695765/746628843321950240/762213788198895639 Block 210781 on Mochimo Discord]<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b...<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24...<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be...<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre><br />
<i>The WOTS were truncated down</i><br><br />
As you can see there's the <i>Change adress</i>, the new sender's WOTS and there's also the <i>Change</i>, the new sender's balance.<br><br><br />
<br />
Every transaction has a <b>fixed fee of 0,0000005 Mochimos</b>. The fee could change in future.<br />
<br><br><br />
After a transaction is sent to the network, the sender's account will be blocked from making other transactions until the transactions block is mined.</div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=411Payment system2020-10-04T08:41:26Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, gets from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this: [https://discord.com/channels/460867662977695765/746628843321950240/762213788198895639 Block 210781 on Mochimo Discord]<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b...<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24...<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be...<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre><br />
<i>The WOTS were truncated down</i><br><br />
As you can see there's the <i>Change adress</i>, the new sender's WOTS and there's also the <i>Change</i>, the new sender's balance.<br><br><br />
<br />
Every transaction has a <b>fixed fee of 0,0000005 Mochimos</b>. The fee could change in future.<br />
<br><br><br />
After a transaction is sent to the network, the sender's account will be blocked from making other transactions until the transactions block is mined.</div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=410Payment system2020-10-04T08:34:39Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, requests from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this: [https://discord.com/channels/460867662977695765/746628843321950240/762213788198895639 Block 210781 on Mochimo Discord]<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b...<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24...<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be...<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre><br />
<i>The WOTS were truncated down</i><br><br />
As you can see there's the <i>Change adress</i>, the new sender's WOTS and there's also the <i>Change</i>, the new sender's balance.<br><br><br />
<br />
Every transaction has a <b>fixed fee of 0,0000005 Mochimos</b>. The fee could change in future.<br />
<br><br><br />
After a transaction is sent to the network, the sender's account will be blocked from making other transactions until the transactions block is mined.</div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=409Payment system2020-10-04T08:33:53Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, requests from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this: [https://discord.com/channels/460867662977695765/746628843321950240/762213788198895639 Block 210781 on Mochimo Discord]<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b...<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24...<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be...<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre><br />
<i>The WOTS were truncated down</i><br><br />
As you can see there's the <i>Change adress</i>, the new sender's WOTS and there's also the <i>Change</i>, the new sender's balance.<br><br><br />
<br><br />
Every transaction has a fixed fee of 0,0000005 Mochimos. The fee could change in future.<br />
<br><br />
After a transaction is sent to the network, the sender's account will be blocked from making other transactions until the transactions block is mined.</div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=408Payment system2020-10-04T08:29:39Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, requests from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this: [https://discord.com/channels/460867662977695765/746628843321950240/762213788198895639 Block 210781 on Mochimo Discord]<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b...<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24...<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be...<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre><br />
<i>The WOTS were truncated down</i><br><br />
As you can see there's the <i>Change adress</i>, the new sender's WOTS and there's also the <i>Change</i>, the new sender's balance.<br><br><br />
<br />
After a transaction is sent to the network, the sender's account will be blocked from making other transactions until the transactions block is mined.</div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=407Payment system2020-10-04T08:22:47Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, requests from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this: [https://discord.com/channels/460867662977695765/746628843321950240/762213788198895639 Block 210781]<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b...<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24...<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be...<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre><br />
<br><br />
<i>This is a real transaction that took from the Discord channel "network stream" of Mochimo's server</i></div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=406Payment system2020-10-04T08:21:41Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, requests from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this:<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre>[https://discord.com/channels/460867662977695765/746628843321950240/762213788198895639 Block 210781]<br />
<br />
<br><br />
<i>This is a real transaction that took from the Discord channel "network stream" of Mochimo's server</i></div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=405Payment system2020-10-04T08:20:47Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, requests from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this:<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre><ref name="Block 210781" /><br><br />
<i>This is a real transaction that took from the Discord channel "network stream" of Mochimo's server</i></div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=404Payment system2020-10-04T08:19:30Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, requests from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this:<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre></ref name="Block 210781"><br><br />
<i>This is a real transaction that took from the Discord channel "network stream" of Mochimo's server</i></div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=403Payment system2020-10-04T08:17:58Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, requests from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this:<br><br />
<pre><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</pre><ref>[https://discord.com/channels/460867662977695765/746628843321950240/762213788198895639 Block 210781], additional text.</ref><br><br />
<i>This is a real transaction that took from the Discord channel "network stream" of Mochimo's server</i></div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=402Payment system2020-10-04T08:15:15Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, requests from the network the latest WOTS of the receiver.<br />
<br><br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br><br />
The transaction will look like this:<br><br />
<code><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</code><br><br />
<i>This is a real transaction that took from the Discord channel "network stream" of Mochimo's server</i></div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=401Payment system2020-10-04T08:14:38Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br />
==Performing a transaction==<br />
<i>All below this refers to the Mojo wallet. If you need a detailed process of all this take a look at the [[Exchange_Integration]]</i><br />
To perform a transaction you have to know your receiver's TAG. The TAG never changes so it's reccomended to use the TAG instead of the whole WOTS.<br />
After you inserted the TAG in the Mojo wallet, it will try to resolve the TAG, or in other words, requests from the network the latest WOTS of the receiver.<br />
<br><br />
After the wallet obtains the receiver's latest WOTS, it will start to generate a new WOTS for the sender account. Obviously the new sender's WOTS will end <br />
with the same TAG as before, but with a different signature because it's very unsafe to use the same signature twice.<br />
<br><br />
The transaction will look like this:<br />
<code><br />
[Block: 210781]<br />
TxID: f5c599904ff2e8fb023f722b37bb28e67d48b0947727afbd3ae7e32e70d66e3b<br />
Source address: wots:4cd4ae7c995ce45dee7ad7812cc2031f58b29e92905d501fe50f97ac6e2fee24<br />
Destination address: tag:01add256a1b1794a83f3c86e<br />
Change address: wots:6e46acafc5c94586e0895484b32342d03017832083f1a6f8eb7a02eca938a8be<br />
Sent: 7.682738943MCM<br />
Change: 0MCM<br />
</code><br />
<i>This is a real transaction that took from the Discord channel "network stream" of Mochimo's server</i></div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=400Payment system2020-10-04T08:01:36Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.<br />
<br><br><br><br />
==Performing a transaction==<br />
All below this refers to the Mojo wallet. If you need a detailed process of all this take a look [[Exchange_Integration]]</div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=399Payment system2020-10-04T07:58:23Z<p>NickP05: </p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The <b>WOTS</b>, as said before, <b>changes at every transaction</b>. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000<br />
The WOTS to be valid should include the <b>unique TAG identifier</b>. In this case to activate a WOTS assigning a TAG you need a special transaction. That transaction is performed by the fountains. They perform a small payment, then the miners will incorporate that transaction in the mining block and, after the block is mined, <b>the TAG is permanently assigned</b>: noone can take it, noone can change it (also the owner can't), unless the account has not the minimum Mochimos required.</div>NickP05http://www.mochiwiki.com/w/index.php?title=Payment_system&diff=398Payment system2020-10-04T07:49:45Z<p>NickP05: Created page with " ==What is a WOTS ?== The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment. The WOTS is usually coded in h..."</p>
<hr />
<div><br />
==What is a WOTS ?==<br />
The WOTS is a unique public identifier for an account. It's the adress that you send to someone else to receive a payment.<br />
The WOTS is usually coded in hexadecimal and is 4416 characters long. It consists of two parts:<br />
# The unique signature<br />
# The TAG<br />
<br />
The first part, the unique signature, is the public key. It changes every time you make a transaction. It's 4392 hexadecimal characters.<br />
The Mojo wallet generates 100 unique signatures by the time you create a wallet. Every signature consists by 2 parts: the public and the private.<br />
The public signature, as said before, makes the first 4392 hexadecimal characters of the WOTS.<br />
<br><br><br />
The WOTS, as said before, changes at every transaction. So how can someone send some Mochimos to someone else?<br />
<br><br />
A WOTS to be enabled should include also the TAG part. The TAG part constists by the last 24 characters of the WOTS. The TAG never changes.<br />
When the WOTS is generated doesn't include a TAG, but it ends with this standard tag:<br />
* 420000000e00000001000000</div>NickP05