mirror of
https://github.com/monero-project/monero-docs.git
synced 2024-12-23 03:59:23 +00:00
224 lines
No EOL
34 KiB
JSON
224 lines
No EOL
34 KiB
JSON
{
|
|
"docs": [
|
|
{
|
|
"location": "/",
|
|
"text": "Unofficial Monero Documentation\n\n\nMonerodocs attempts to organize basic technical knowledge on Monero in one place.\n\n\nThe goal is to educate and onboard power users faster.\n\n\nWhile technical explanations are out there, the information is scattered through reddit posts, git comments, stack exchange answers, chat logs and the source code. This makes it hard to find complete and up-to-date explanations on advanced topics.\n\n\nIf you spot errors or issues please kindly drop me an email at \nqertoip@gmail.com\n or submit a github pull request.",
|
|
"title": "Unofficial Monero Documentation"
|
|
},
|
|
{
|
|
"location": "/#unofficial-monero-documentation",
|
|
"text": "Monerodocs attempts to organize basic technical knowledge on Monero in one place. The goal is to educate and onboard power users faster. While technical explanations are out there, the information is scattered through reddit posts, git comments, stack exchange answers, chat logs and the source code. This makes it hard to find complete and up-to-date explanations on advanced topics. If you spot errors or issues please kindly drop me an email at qertoip@gmail.com or submit a github pull request.",
|
|
"title": "Unofficial Monero Documentation"
|
|
},
|
|
{
|
|
"location": "/Monero-Base58/",
|
|
"text": "Base58\n\n\nBase58 is a binary-to-text encoding scheme. It is similar to Base64 but has been modified to avoid both non-alphanumeric characters and letters which might look ambiguous when printed. The characters excluded in relation to Base64 are: \nIOl0+/\n\n\nBase58 does not strictly specify the format. This results in some implementations being incompatible with others, for example with regard to alphabet order.\n\n\nFor details, see \nWikipedia\n.\n\n\nBase58 in Monero\n\n\nMonero has its own variant of Base58.\n\n\nIn Monero the Base58 encoding is performed in 8-byte blocks, except the last block which is the remaining (8 or less) bytes .\n\n\nThe 8-byte block converts to 11 or less Base58 characters. If the block converted to less then 11 characters, the output is padded with \"1\"s (0 in Base58). The final block is padded as well to whatever would be the maximum size of this number of bytes encoded in Base58.\n\n\nThe advantage of Monero implementation is that output is of a fixed size which is not the case with plain Base58. The disadvantage is that default libraries won't work.\n\n\nFor details, see \nreference C++ Base58\n implementation and \nunofficial Python Base58\n implementation.",
|
|
"title": "Base58"
|
|
},
|
|
{
|
|
"location": "/Monero-Base58/#base58",
|
|
"text": "Base58 is a binary-to-text encoding scheme. It is similar to Base64 but has been modified to avoid both non-alphanumeric characters and letters which might look ambiguous when printed. The characters excluded in relation to Base64 are: IOl0+/ Base58 does not strictly specify the format. This results in some implementations being incompatible with others, for example with regard to alphabet order. For details, see Wikipedia .",
|
|
"title": "Base58"
|
|
},
|
|
{
|
|
"location": "/Monero-Base58/#base58-in-monero",
|
|
"text": "Monero has its own variant of Base58. In Monero the Base58 encoding is performed in 8-byte blocks, except the last block which is the remaining (8 or less) bytes . The 8-byte block converts to 11 or less Base58 characters. If the block converted to less then 11 characters, the output is padded with \"1\"s (0 in Base58). The final block is padded as well to whatever would be the maximum size of this number of bytes encoded in Base58. The advantage of Monero implementation is that output is of a fixed size which is not the case with plain Base58. The disadvantage is that default libraries won't work. For details, see reference C++ Base58 implementation and unofficial Python Base58 implementation.",
|
|
"title": "Base58 in Monero"
|
|
},
|
|
{
|
|
"location": "/Multisignature/",
|
|
"text": "Multisignature\n\n\n!! This is unreleased feature !!\n\n\nIn cryptocurrencies, multisig feature allows to sign transaction with more than one private key. Funds protected with multisig can only be spent by signing with M-of-N keys.\n\n\nExample use cases:\n\n\n\n\nshared account (1-of-2; both husband and wife individually have full access to their funds)\n\n\nconsensus account (2-of-2; both husband and wife must agree to spend their funds)\n\n\nthreshold account (2-of-3; an escrow service is involved as an independent 3rd party, to co-sign with either the seller, or with the buyer, if seller and buyer do not agree)\n\n\nsecure account (2-of-3; a single owner controlls all 3 keys but secures them via a different means to diversify risks)\n\n\narbitrary threshold account (M-of-N; some cryptocurrencies provide full flexibility on the number of signers)\n\n\n\n\nMonero multisignature\n\n\nMonero doesn't directly implement multisignatures (at least not in a classical sense). Monero emulates the feature by secret splitting.\n\n\nTransactions are still signed with a single spend key. The spend key is a sum of all N private keys. The rationale for such design is to decouple multisig from ring signatures.\n\n\nLet's consider the 2-of-3 scheme. We have 3 participants. Each participant is granted exactly 2 private keys in a way that pairs do not repeat between participants. This way any 2 participants together have all 3 private keys required to create the private spend key.\n\n\nMulti-signing is a wallet-level feature. There is no way to learn from the blockchain which transactions were created using multiple signatures.\n\n\nIt is also worth noting in Monero there is no multisig addresses as such. \nAddress structure\n does not care how the underlying private spend key got created.\n\n\nIn Monero, only N-of-N and (N-1)-of-N multisignature schemes are supported. This covers all common scenarios mentioned above but does not allow for arbitrary voting (like \"3-of-5 board members\").\n\n\nAfter multisig wallet setup every participant ends up knowing the public address and private view key. This is necessary for participants to recognize and decipher transactions they are supposed to co-sign.\n\n\nMultisig wallet setup\n\n\nLet's consider a 2-of-3 scheme as it generalizes well. There will be three CLI wallet commands involved:\n\n\n1. prepare_multisig\n\n\nEvery participant independently generates \ninitialization data\n. This is \nnot\n an address.\n\n\nEvery participant sends his initialization data manually to all other participants over secure channel.\n\n\n2. make_multisig\n\n\nEvery participant applies initialization data from other participants. This results in a \nsecond round of initialization data\n. This is still \nnot\n an address.\n\n\nEvery participants sends his second round of init data to all other participants over secure channel.\n\n\n3. finalize_multisig\n\n\nEvery participant finalizes wallet creation by applying the second round of init data from all other participants. This finally results in a wallet \npublic address\n and \nprivate view key\n to be known for all participants. \n\n\nPlease note actions are symmetric for all participants. Even though we considered a 2-of-3 scheme, every participant cooperates with everyone else. The secret splitting is performed internally by the wallet.\n\n\nSecure sharing of initialization data between participants is manual. The wallet itself does not provide any secure communication channel. This is out of scope.\n\n\nReceiving funds\n\n\nAddress built by multisig setup is like any other address.\n\n\nYou can generate integrated addresses and subaddresses based on it.\n\n\nAll participants are able to see incoming funds as they share the private view key.\n\n\nWith a CLI, use the following commands to see incoming payments:\n\n\naddress\nrefresh\nshow_transfers\n\n\n\nSpending funds\n\n\nTODO\n\n\nReference\n\n\n\n\nhttps://monero.stackexchange.com/questions/5646/how-to-use-monero-multisignature-wallets-2-2-2-3",
|
|
"title": "Multisignature"
|
|
},
|
|
{
|
|
"location": "/Multisignature/#multisignature",
|
|
"text": "!! This is unreleased feature !! In cryptocurrencies, multisig feature allows to sign transaction with more than one private key. Funds protected with multisig can only be spent by signing with M-of-N keys. Example use cases: shared account (1-of-2; both husband and wife individually have full access to their funds) consensus account (2-of-2; both husband and wife must agree to spend their funds) threshold account (2-of-3; an escrow service is involved as an independent 3rd party, to co-sign with either the seller, or with the buyer, if seller and buyer do not agree) secure account (2-of-3; a single owner controlls all 3 keys but secures them via a different means to diversify risks) arbitrary threshold account (M-of-N; some cryptocurrencies provide full flexibility on the number of signers)",
|
|
"title": "Multisignature"
|
|
},
|
|
{
|
|
"location": "/Multisignature/#monero-multisignature",
|
|
"text": "Monero doesn't directly implement multisignatures (at least not in a classical sense). Monero emulates the feature by secret splitting. Transactions are still signed with a single spend key. The spend key is a sum of all N private keys. The rationale for such design is to decouple multisig from ring signatures. Let's consider the 2-of-3 scheme. We have 3 participants. Each participant is granted exactly 2 private keys in a way that pairs do not repeat between participants. This way any 2 participants together have all 3 private keys required to create the private spend key. Multi-signing is a wallet-level feature. There is no way to learn from the blockchain which transactions were created using multiple signatures. It is also worth noting in Monero there is no multisig addresses as such. Address structure does not care how the underlying private spend key got created. In Monero, only N-of-N and (N-1)-of-N multisignature schemes are supported. This covers all common scenarios mentioned above but does not allow for arbitrary voting (like \"3-of-5 board members\"). After multisig wallet setup every participant ends up knowing the public address and private view key. This is necessary for participants to recognize and decipher transactions they are supposed to co-sign.",
|
|
"title": "Monero multisignature"
|
|
},
|
|
{
|
|
"location": "/Multisignature/#multisig-wallet-setup",
|
|
"text": "Let's consider a 2-of-3 scheme as it generalizes well. There will be three CLI wallet commands involved:",
|
|
"title": "Multisig wallet setup"
|
|
},
|
|
{
|
|
"location": "/Multisignature/#1-prepare_multisig",
|
|
"text": "Every participant independently generates initialization data . This is not an address. Every participant sends his initialization data manually to all other participants over secure channel.",
|
|
"title": "1. prepare_multisig"
|
|
},
|
|
{
|
|
"location": "/Multisignature/#2-make_multisig",
|
|
"text": "Every participant applies initialization data from other participants. This results in a second round of initialization data . This is still not an address. Every participants sends his second round of init data to all other participants over secure channel.",
|
|
"title": "2. make_multisig"
|
|
},
|
|
{
|
|
"location": "/Multisignature/#3-finalize_multisig",
|
|
"text": "Every participant finalizes wallet creation by applying the second round of init data from all other participants. This finally results in a wallet public address and private view key to be known for all participants. Please note actions are symmetric for all participants. Even though we considered a 2-of-3 scheme, every participant cooperates with everyone else. The secret splitting is performed internally by the wallet. Secure sharing of initialization data between participants is manual. The wallet itself does not provide any secure communication channel. This is out of scope.",
|
|
"title": "3. finalize_multisig"
|
|
},
|
|
{
|
|
"location": "/Multisignature/#receiving-funds",
|
|
"text": "Address built by multisig setup is like any other address. You can generate integrated addresses and subaddresses based on it. All participants are able to see incoming funds as they share the private view key. With a CLI, use the following commands to see incoming payments: address\nrefresh\nshow_transfers",
|
|
"title": "Receiving funds"
|
|
},
|
|
{
|
|
"location": "/Multisignature/#spending-funds",
|
|
"text": "TODO",
|
|
"title": "Spending funds"
|
|
},
|
|
{
|
|
"location": "/Multisignature/#reference",
|
|
"text": "https://monero.stackexchange.com/questions/5646/how-to-use-monero-multisignature-wallets-2-2-2-3",
|
|
"title": "Reference"
|
|
},
|
|
{
|
|
"location": "/Public-Address/",
|
|
"text": "Public Address\n\n\nMonero public address is what you publish to get paid.\n\n\nAn address can be generated offline and for free. It boils down to generating a large random number representing your private spending key.\n\n\nPublishing your Monero address does \nnot\n endanger your privacy. That's because in Monero transactions go to stealth addresses which are decoupled from your public address.\n\n\nThere are a few types of public addresses in Monero:\n\n\n\n\nStandard address - the basic type of the address, also refered to as raw address\n\n\nIntegrated address - embeds payment ID so you can learn for what you are being paid\n\n\nSubaddress - allows for organizing your funds in subaccounts within a single wallet\n\n\n\n\nStandard address\n\n\nMonero standard (\"raw\") address is composed of two public keys:\n\n\n\n\npublic spend key\n\n\npublic view key\n\n\n\n\nIt also contains a checksum and a \"network byte\" which actually identifies both the network and the address type.\n\n\nData structure (\nsrc\n):\n\n\n\n\n\n\n\n\nIndex\n\n\nSize in bytes\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\n0\n\n\n1\n\n\nidentifies the network and address type; \n18\n - main chain; \n53\n - test chain\n\n\n\n\n\n\n1\n\n\n32\n\n\npublic spend key\n\n\n\n\n\n\n33\n\n\n32\n\n\npublic view key\n\n\n\n\n\n\n65\n\n\n4\n\n\nchecksum (\nKeccak-f[1600] hash\n of the previous 65 bytes, trimmed to first \n4\n bytes)\n\n\n\n\n\n\n\n\nIt totals to 69 bytes. The bytes are then encoded (\nsrc\n) in \nMonero specific Base58\n format, resulting in a 95 chars long string. Example standard address:\n\n\n4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2684Rge\n\n\nReference:\n\n\n\n\nhttps://xmr.llcoins.net/addresstests.html\n\n\n\n\nIntegrated address\n\n\nMonero integrated address embeds a compact payment ID.\n\n\nMonero integrated address obsoletes the former practice of using full 32-bytes payment ID in a transaction extra field (where it was not encrypted).\n\n\nData structure (\nsrc\n):\n\n\n\n\n\n\n\n\nIndex\n\n\nSize in bytes\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\n0\n\n\n1\n\n\nidentifies the network and address type; \n19\n - main chain; \n54\n - test chain\n\n\n\n\n\n\n1\n\n\n32\n\n\npublic spend key\n\n\n\n\n\n\n33\n\n\n32\n\n\npublic view key\n\n\n\n\n\n\n65\n\n\n8\n\n\ncompact payment ID - 8 bytes randomly generated by the recipient; note that it does not need encryption in the address itself but it is hidden in a transaction paying to integrated address to prevent linking payment with the address by external observers\n\n\n\n\n\n\n73\n\n\n4\n\n\nchecksum (\nKeccak-f[1600] hash\n of the previous 73 bytes, trimmed to first \n4\n bytes)\n\n\n\n\n\n\n\n\nIt totals to 78 bytes. The bytes are then encoded (\nsrc\n) in \nMonero specific Base58\n format, resulting in a 106 chars long string. Example integrated address:\n\n\n4LL9oSLmtpccfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2bYXZKKQePHES9khPK\n\n\nReference:\n\n\n\n\nquestion on \nStackExchenge\n \n\n\n\n\nSubaddress\n\n\nSubaddresses serve two purposes.\n\n\nSubadresses group incoming payments\n\n\nThink income streams.\n\n\nSubaddresses allow you to group your incoming transactions within a single wallet.\n\n\nYou may want to organize your incoming funds into a streams like \"donations\", \"work\", \"speculation\", etc.\n\n\nAt first glance this is similar to subaccounts in your bank account. There is a very important difference though.\n\n\nIn Monero funds don't really sit on public addresses. Public addresses are conceptually a gateway or a routing mechanism. Funds sit on the unspent outputs. Thus, a single transaction can aggregate and spent outputs from multiple addresses. This means you can spend more than any individual address balance.\n\n\nSubadresses prevent payer from linking your payouts together\n\n\nTo prevent the payer from linking your payouts together simply generate a new subaddress for each payout. This way services like \nShapeshift\n wouldn't know it is you again receving Monero.\n\n\nThe advantage over creating multiple wallets is that you only have a single seed and wallet cache to manage. All subaddresses can be derived from the wallet seed.\n\n\nEach subaddress has an index (with 0 being the base standard address). User interface allows to assign convenience labels to subaddresses. However, labels are not preserved when recreating from seed.\n\n\nCaveates\n\n\n\n\nSubaddress cannot be used to receive transactions having multiple destinations (e.g. pool payouts). Only the standard address (the one with index == 0) can receive such transactions.\n\n\nIt is not recommended to sweep all the balances of subaddress to main address in a single transaction. That links the subaddresses together on the blockchain. However, this only concerns privacy against specific sender and the situation will never get worse than not using subaddresses in the first place. If you need to join funds while preserving maximum privacy do it with individual transactions (one per subaddress).\n\n\n\n\n\n\n\n\n\n\nIndex\n\n\nSize in bytes\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\n0\n\n\n1\n\n\nidentifies the network and address type; \n42\n - main chain; \n63\n - test chain\n\n\n\n\n\n\n\n\nReference:\n\n\n\n\nhttps://github.com/monero-project/monero/pull/2056\n\n\nhttps://www.reddit.com/r/Monero/comments/5vgjs2/subaddresses_and_disposable_addresses/",
|
|
"title": "Public Address"
|
|
},
|
|
{
|
|
"location": "/Public-Address/#public-address",
|
|
"text": "Monero public address is what you publish to get paid. An address can be generated offline and for free. It boils down to generating a large random number representing your private spending key. Publishing your Monero address does not endanger your privacy. That's because in Monero transactions go to stealth addresses which are decoupled from your public address. There are a few types of public addresses in Monero: Standard address - the basic type of the address, also refered to as raw address Integrated address - embeds payment ID so you can learn for what you are being paid Subaddress - allows for organizing your funds in subaccounts within a single wallet",
|
|
"title": "Public Address"
|
|
},
|
|
{
|
|
"location": "/Public-Address/#standard-address",
|
|
"text": "Monero standard (\"raw\") address is composed of two public keys: public spend key public view key It also contains a checksum and a \"network byte\" which actually identifies both the network and the address type. Data structure ( src ): Index Size in bytes Description 0 1 identifies the network and address type; 18 - main chain; 53 - test chain 1 32 public spend key 33 32 public view key 65 4 checksum ( Keccak-f[1600] hash of the previous 65 bytes, trimmed to first 4 bytes) It totals to 69 bytes. The bytes are then encoded ( src ) in Monero specific Base58 format, resulting in a 95 chars long string. Example standard address: 4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2684Rge Reference: https://xmr.llcoins.net/addresstests.html",
|
|
"title": "Standard address"
|
|
},
|
|
{
|
|
"location": "/Public-Address/#integrated-address",
|
|
"text": "Monero integrated address embeds a compact payment ID. Monero integrated address obsoletes the former practice of using full 32-bytes payment ID in a transaction extra field (where it was not encrypted). Data structure ( src ): Index Size in bytes Description 0 1 identifies the network and address type; 19 - main chain; 54 - test chain 1 32 public spend key 33 32 public view key 65 8 compact payment ID - 8 bytes randomly generated by the recipient; note that it does not need encryption in the address itself but it is hidden in a transaction paying to integrated address to prevent linking payment with the address by external observers 73 4 checksum ( Keccak-f[1600] hash of the previous 73 bytes, trimmed to first 4 bytes) It totals to 78 bytes. The bytes are then encoded ( src ) in Monero specific Base58 format, resulting in a 106 chars long string. Example integrated address: 4LL9oSLmtpccfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2bYXZKKQePHES9khPK Reference: question on StackExchenge",
|
|
"title": "Integrated address"
|
|
},
|
|
{
|
|
"location": "/Public-Address/#subaddress",
|
|
"text": "Subaddresses serve two purposes.",
|
|
"title": "Subaddress"
|
|
},
|
|
{
|
|
"location": "/Public-Address/#subadresses-group-incoming-payments",
|
|
"text": "Think income streams. Subaddresses allow you to group your incoming transactions within a single wallet. You may want to organize your incoming funds into a streams like \"donations\", \"work\", \"speculation\", etc. At first glance this is similar to subaccounts in your bank account. There is a very important difference though. In Monero funds don't really sit on public addresses. Public addresses are conceptually a gateway or a routing mechanism. Funds sit on the unspent outputs. Thus, a single transaction can aggregate and spent outputs from multiple addresses. This means you can spend more than any individual address balance.",
|
|
"title": "Subadresses group incoming payments"
|
|
},
|
|
{
|
|
"location": "/Public-Address/#subadresses-prevent-payer-from-linking-your-payouts-together",
|
|
"text": "To prevent the payer from linking your payouts together simply generate a new subaddress for each payout. This way services like Shapeshift wouldn't know it is you again receving Monero. The advantage over creating multiple wallets is that you only have a single seed and wallet cache to manage. All subaddresses can be derived from the wallet seed. Each subaddress has an index (with 0 being the base standard address). User interface allows to assign convenience labels to subaddresses. However, labels are not preserved when recreating from seed.",
|
|
"title": "Subadresses prevent payer from linking your payouts together"
|
|
},
|
|
{
|
|
"location": "/Public-Address/#caveates",
|
|
"text": "Subaddress cannot be used to receive transactions having multiple destinations (e.g. pool payouts). Only the standard address (the one with index == 0) can receive such transactions. It is not recommended to sweep all the balances of subaddress to main address in a single transaction. That links the subaddresses together on the blockchain. However, this only concerns privacy against specific sender and the situation will never get worse than not using subaddresses in the first place. If you need to join funds while preserving maximum privacy do it with individual transactions (one per subaddress). Index Size in bytes Description 0 1 identifies the network and address type; 42 - main chain; 63 - test chain Reference: https://github.com/monero-project/monero/pull/2056 https://www.reddit.com/r/Monero/comments/5vgjs2/subaddresses_and_disposable_addresses/",
|
|
"title": "Caveates"
|
|
},
|
|
{
|
|
"location": "/Subaddress/",
|
|
"text": "Subaddress\n\n\nSubaddresses serve two purposes.\n\n\nPrevent payer from linking your payouts together\n\n\nTo prevent the payer from linking your payouts together simply generate a new subaddress for each payout. This way services like \nShapeshift\n wouldn't know it is you again receving Monero.\n\n\nGroup incoming payments\n\n\nThink income streams.\n\n\nSubaddresses allow you to group your incoming transactions within a single wallet.\n\n\nYou may want to organize your incoming funds into a streams like \"donations\", \"work\", \"pool payouts\", etc.\n\n\nAt first glance this is similar to subaccounts in your bank account. There is a very important difference though.\n\n\nIn Monero funds don't really sit on public addresses. Public addresses are conceptually a gateway or a routing mechanism. Funds sit on the unspent outputs. Thus, a single transaction can aggregate and spent outputs from multiple addresses. This means you can spend more than any individual address balance.\n\n\nWhy not multiple wallets?\n\n\nThe advantage over creating multiple wallets is that you only have a single seed to manage. All subaddresses can be derived from the wallet seed.\n\n\nCaveates\n\n\n\n\nSubaddress \ncannot\n be used to receive transactions having multiple destinations (e.g. pool payouts). Only the standard address (the one with index == 0) can receive such transactions.\n\n\nIt is not recommended to sweep all the balances of subaddress to main address in a single transaction. That links the subaddresses together on the blockchain. However, this only concerns privacy against specific sender and the situation will never get worse than not using subaddresses in the first place. If you need to join funds while preserving maximum privacy do it with individual transactions (one per subaddress).\n\n\n\n\nImplementation\n\n\nEach subaddress has an index (with 0 being the base standard address). User interface allows to assign convenience labels to subaddresses. However, labels are not preserved when recreating from seed.\n\n\n\n\n\n\n\n\nIndex\n\n\nSize in bytes\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\n0\n\n\n1\n\n\nidentifies the network and address type; \n42\n - main chain; \n63\n - test chain\n\n\n\n\n\n\n\n\nTODO: finish\n\n\nReference\n\n\n\n\nhttps://github.com/monero-project/monero/pull/2056\n\n\nhttps://www.reddit.com/r/Monero/comments/5vgjs2/subaddresses_and_disposable_addresses/",
|
|
"title": "Subaddress"
|
|
},
|
|
{
|
|
"location": "/Subaddress/#subaddress",
|
|
"text": "Subaddresses serve two purposes.",
|
|
"title": "Subaddress"
|
|
},
|
|
{
|
|
"location": "/Subaddress/#prevent-payer-from-linking-your-payouts-together",
|
|
"text": "To prevent the payer from linking your payouts together simply generate a new subaddress for each payout. This way services like Shapeshift wouldn't know it is you again receving Monero.",
|
|
"title": "Prevent payer from linking your payouts together"
|
|
},
|
|
{
|
|
"location": "/Subaddress/#group-incoming-payments",
|
|
"text": "Think income streams. Subaddresses allow you to group your incoming transactions within a single wallet. You may want to organize your incoming funds into a streams like \"donations\", \"work\", \"pool payouts\", etc. At first glance this is similar to subaccounts in your bank account. There is a very important difference though. In Monero funds don't really sit on public addresses. Public addresses are conceptually a gateway or a routing mechanism. Funds sit on the unspent outputs. Thus, a single transaction can aggregate and spent outputs from multiple addresses. This means you can spend more than any individual address balance.",
|
|
"title": "Group incoming payments"
|
|
},
|
|
{
|
|
"location": "/Subaddress/#why-not-multiple-wallets",
|
|
"text": "The advantage over creating multiple wallets is that you only have a single seed to manage. All subaddresses can be derived from the wallet seed.",
|
|
"title": "Why not multiple wallets?"
|
|
},
|
|
{
|
|
"location": "/Subaddress/#caveates",
|
|
"text": "Subaddress cannot be used to receive transactions having multiple destinations (e.g. pool payouts). Only the standard address (the one with index == 0) can receive such transactions. It is not recommended to sweep all the balances of subaddress to main address in a single transaction. That links the subaddresses together on the blockchain. However, this only concerns privacy against specific sender and the situation will never get worse than not using subaddresses in the first place. If you need to join funds while preserving maximum privacy do it with individual transactions (one per subaddress).",
|
|
"title": "Caveates"
|
|
},
|
|
{
|
|
"location": "/Subaddress/#implementation",
|
|
"text": "Each subaddress has an index (with 0 being the base standard address). User interface allows to assign convenience labels to subaddresses. However, labels are not preserved when recreating from seed. Index Size in bytes Description 0 1 identifies the network and address type; 42 - main chain; 63 - test chain TODO: finish",
|
|
"title": "Implementation"
|
|
},
|
|
{
|
|
"location": "/Subaddress/#reference",
|
|
"text": "https://github.com/monero-project/monero/pull/2056 https://www.reddit.com/r/Monero/comments/5vgjs2/subaddresses_and_disposable_addresses/",
|
|
"title": "Reference"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/",
|
|
"text": "Technical Specs\n\n\nNo premine, no instamine, no token\n\n\n\n\nMonero had no premine or instamine\n\n\nMonero did not sell any token\n\n\nMonero had no presale of any kind\n\n\n\n\nProof of Work\n\n\n\n\nCryptoNight\n\n\nmay change in the future\n\n\n\n\nDifficulty retarget\n\n\n\n\nevery block\n\n\nbased on the last 720 blocks, excluding 20% of the timestamp outliers\n\n\n\n\nBlock time\n\n\n\n\n2 minutes\n\n\nmay change in the future as long as emission curve is preserved\n\n\n\n\nBlock reward\n\n\n\n\n~6 XMR as of Dec 2017, see the \nlatest block\n coinbase transaction amount for current reward\n\n\nsmoothly decreasing and subject to penalties for blocks greater then median size of the last 100 blocks (M100)\n\n\n\n\nBlock size\n\n\n\n\ndynamic, maximum of two times median size of the last 100 blocks (2 * M100)\n\n\n\n\nEmission curve\n\n\nMain curve\n\n\nFirst, the main emission is about to produce ~18.132 million coins by the end of May 2022.\n\n\nAs of Dec 2017 the emission is about 30 XMR per 10 minutes.\n\n\nSee \ncharts and details\n.\n\n\nTail curve\n\n\nThe tail emission kicks in once main emission is done.\n\n\nIt will produce 0.6 XMR per 2-minute block.\n\n\nThis translates to <1% inflation decreasing over time.\n\n\nMax supply\n\n\n\n\ninfinite\n\n\n\n\nSender privacy\n\n\n\n\nRing signatures\n\n\n\n\nRecipient privacy\n\n\n\n\nStealth addresses\n\n\n\n\nAmount obfuscation\n\n\n\n\nRing confidential transactions",
|
|
"title": "Technical Specs"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#technical-specs",
|
|
"text": "",
|
|
"title": "Technical Specs"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#no-premine-no-instamine-no-token",
|
|
"text": "Monero had no premine or instamine Monero did not sell any token Monero had no presale of any kind",
|
|
"title": "No premine, no instamine, no token"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#proof-of-work",
|
|
"text": "CryptoNight may change in the future",
|
|
"title": "Proof of Work"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#difficulty-retarget",
|
|
"text": "every block based on the last 720 blocks, excluding 20% of the timestamp outliers",
|
|
"title": "Difficulty retarget"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#block-time",
|
|
"text": "2 minutes may change in the future as long as emission curve is preserved",
|
|
"title": "Block time"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#block-reward",
|
|
"text": "~6 XMR as of Dec 2017, see the latest block coinbase transaction amount for current reward smoothly decreasing and subject to penalties for blocks greater then median size of the last 100 blocks (M100)",
|
|
"title": "Block reward"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#block-size",
|
|
"text": "dynamic, maximum of two times median size of the last 100 blocks (2 * M100)",
|
|
"title": "Block size"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#emission-curve",
|
|
"text": "Main curve First, the main emission is about to produce ~18.132 million coins by the end of May 2022. As of Dec 2017 the emission is about 30 XMR per 10 minutes. See charts and details . Tail curve The tail emission kicks in once main emission is done. It will produce 0.6 XMR per 2-minute block. This translates to <1% inflation decreasing over time.",
|
|
"title": "Emission curve"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#max-supply",
|
|
"text": "infinite",
|
|
"title": "Max supply"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#sender-privacy",
|
|
"text": "Ring signatures",
|
|
"title": "Sender privacy"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#recipient-privacy",
|
|
"text": "Stealth addresses",
|
|
"title": "Recipient privacy"
|
|
},
|
|
{
|
|
"location": "/Technical-Specs/#amount-obfuscation",
|
|
"text": "Ring confidential transactions",
|
|
"title": "Amount obfuscation"
|
|
}
|
|
]
|
|
} |