Key offsets are the set of outputs your ring is using as "fake"outputs, as well as yours. Outputs of a given denomination are ordered in blockchain order, and thus can be represented by their index in that list. This is smaller than using the public key. Moreover, they're stored as offsets from the previous one (the first one from 0), as this will result in ...
I can't tell you why it currently (version 0.10.0.0) is not enabled by default. However, about 10 days ago I filed an issue (#1058) for this on GitHub. Meanwhile, it seems there's a pull request in the works (#1185) to actually enable this by default in the future.
From what I know about testnet, you can run a sort of "fork" of a code with other people to test if it's works or not before you put it into an actual fork. For example, people have recently been testing Ring CT on test net to work out any bugs and then correct them.
You can connect and help the testing in the network by still using the same daemon and ...
You can create your own testnet by running two local nodes, and run a miner locally that mines on the local node blockchain. It has been covered in a reddit thread here: https://www.reddit.com/r/Monero/comments/3x5qwo/how_do_i_make_my_own_testnet_network_with_eg_two/
/opt/bitmonero/bitmonerod --testnet --testnet-p2p-bind-port 38080 --no-igd --hide-...
You can help by performing the most unlikely actions that should still work, keeping track of what you do, and reporting what doesn't work.
Sending transactions to other addresses is the obvious case, which has been well tested already. Things worth testing now are features that were added recently to the git repository, such as cold wallet signing.
You don't. Subaddresses also solve the problem integrated addresses were designed for (allowing source identification in a single address). Since you can now generate a subaddress per source/client/customer, you don't need to assign a payment id anymore, so the ability to make integrated subaddresses was not added.
Yes, this is possible. Someone on Reddit, made a public testnet wallet, from which you could transfer some moneroj to your own address(es), to experiment with (e.g. cold signing, etcetera).
First create your own testnet wallet(s), and then you'll need create another wallet to restore from the mnemonic seed posted in the Reddit article. From that one, you ...
If you pop into /r/monero on reddit, or on Slack/IRC #monero, you will find people who would be happy to send you testnet coins.
Alternatively, it is rather satisfying to mine your own. The difficulty on the testnet is quite low, so odds are high that you will see returns in the first day or two. I highly recommend it.
So the transaction splitting function is not an anonymity thing, it's due to the dynamic block size limiter. Right now testnet is on the block median, and you're trying to create a transaction that is much larger than that block limit. So it tries to split the transaction up into several that fit into the block limit, but if it needs to create thousands of ...
There will be a public testnet once there is some code review.
I'm not sure whether the code will be merged prior to the public testnet or not. If it is, then you will be able to pull from master and run in testnet mode. If not, you will have to build from moneromooo's branch. From today's dev meeting, the testnet should happen a few days after the PR ...
I couldn't find a public remote testnet node, so I created one on a VPS.
Here's the address...
If you're testing the official CLI wallet, include these options...
./monero-wallet-cli --testnet --daemon-address 22.214.171.124:38081
If you're testing the official GUI wallet, you need to do the following...
Prefix is fixed in that the first (AKA network) byte is fixed to 0x35 for testnet. When encoding to base58 to get the actual address, the first 2 characters will vary depending on what follows after the network byte.
Those 2 addresses decode to:
The argument is the filename to be used. It would be bad practice to enter the seed as an argument when starting the program, as your command shell could keep logs of recent commands which would then leave some record of your seed somewhere on your HDD. So, only the filename is provided as the starting argument, and all the other info (password, keys, ...
The generate from keys switch requires the private spend key, view key, and public address in order to recreate the wallet. The first piece of info it requested was probably a filename to save to, not the seed. It is what you use when you have all the raw information, but not the seed.
It you want to restore from seed, you need to use the
Using Wolfram Warptangent v0.10.0 release fixed this problem.
However, I found just using the regular public testnet works better than a private testnet . It is difficult to find enough mixins in private testnet. The minimum mixin is 4.
This has been fixed by pull request #1225. You can compile from source to benefit now or wait for the next official release.
- GET_FIELD_FROM_JSON_RETURN_ON_ERROR(json, always_confirm_transfers, int, Int, false, false);
- m_always_confirm_transfers = field_always_confirm_transfers_found && field_always_confirm_transfers;
I am not aware of any other Monero forks besides the two that you mentioned.
There are other CryptoNote currencies but I am not aware of any that have a public testnet. The level of community and developer interest in most other CryptoNote projects is minuscule compared to Monero. Most CryptoNote coins were originally forked from Bytecoin with development ...
You need a more recent version to use the public testnet. In particular, the public testnet is currently running v7, while 0.11.1.0 only knows up to v6.
At some point, the testnet will also be reorganized as bulletproofs will be moved to v8, and v7 will be re-mined, so be aware that coins you mine on testnet on v7 will go poof at some point.
Start the daemon: monerod --testnet and then once sync'ed...
Start the wallet in another window: monero-wallet-cli --testnet to create a testnet wallet, then...
Back in the running daemon type: start_mining <your-wallet-address-here>
Wait to mine a block. You'll then have testnet coins.
Perhaps there are not sufficient other transactions to participate in a ring on testnet for the amounts that you are trying to transact. Since a ring is required, no zero mixin transactions are allowed, you would have to try transactions in other (smaller) amounts.
Total and fee calculation seems to happen here:
// give user total and fee, and prompt to confirm
uint64_t total_fee = 0, total_unmixable = 0;
for (size_t n = 0; n < ptx_vector.size(); ++n)
total_fee += ptx_vector[n].fee;
for (const auto &vin: ptx_vector[n].tx.vin)
if (vin.type() == typeid(txin_to_key))
total_unmixable += boost::...
If the rules are the same as on the main network, you need to wait 60 blocks (ca. 2 hours) to see the balance unlocked for coins that you mine.
For normal transactions, the balance is locked for 10 blocks only (ca. 20 minutes).
Monero does not use the height, but that doesn't mean a fork cannot. Just pass the block height to get_block_reward (in src/cryptonote_basic/cryptonote_basic_impl.cpp) and you're set. Don't forget to update the tests :)
Monero private testnet setup - https://github.com/moneroexamples/private-testnet
Test faucet - see Can I obtain Monero testnet coins without mining?