Monero doesn't use EdDSA, which all of those libraries are specifically set up for. We don't use SHA512 at all, but rather Keccak (~SHA3). We don't use secret keys as seeds like EdDSA does, but rather as scalars. If you look at ed25519.py on L63, you can see what I'm talking about.
Change the function to look like this:
a = decodeint(...
They're all Poloniex's deposit address. The bit at the end is the payment ID used to identify the depositor's Poloniex account. You can read more about integrated addresses here: What is an integrated address?
Monero makes no attempt to encrypt or obfuscate the data being sent between peers. A passive attacker could monitor the transactions in the same manner to identify the IP that originated a particular transaction.
Unlike Bitcoin, Monero transactions always use ring signatures and always mask recipient addresses (I don't remember if the latter is enforced by ...
The question should be answered here:
Monero private key collision
TL;DR: There are 2^256 possible private spend keys, which would take 3.67×10^66 years to generate all of them at a rate of 1000 per second.
So while it is theoretically possible to have someone else generate the same key, as long as there is a large enough entropy pool for the random ...
QR-codes have nothing specific to Monero. They are just a 2D representation of a string.
It should work with any qr-code tool, and for any alphanumeric string of less than 4296 characters. So this includes monero public keys, private keys and integrated addresses.
For example on Linux :
Install packages : apt-get install qrencode zbar-tools
Generate a QR-...
The base58 encoding used in Bitcoin converts all the data to an integer, and then encodes it using divisions by 58. If there is a lot of data, the integer will get very big, which requires having a library dealing with bignums. And usually bignum operations (in this case bignum divisions) are not very fast.
Encoding the data by blocks of 8 bytes at most is ...
The general idea is to hash the string (preferably using a KDF), and use the resulting hash as the spend key. The view key ...
You need to use a vanity address generator. As far as I know, this one written in Go is the best/only available one:
It's an interesting idea, and yes it would be possible to do. All you'd have to do is define some convention to make the conversion and have it coded. Then, if people like it, it could stick around and start to be used widely.
Personally, I wouldn't use it, as the string of words would be much longer than the base58 one. Consider a bigger dictionary than ...
It is impossible for a miner or any other blockchain observer to know whether any transactions are destined for a particular wallet address (or wallet account). This is because wallet addresses do not appear on the blockchain at all.
Monero instead uses stealth addressing, which encrypts the destination of the transaction such that only the recipient can ...
In terms of cryptography: no, unless the vanity generator is badly implemented, without a proper source of entropy.
Although, if you use an untrusted vanity generator, they could record your private key and send it somewhere. Good old trick.
Two people might independently generate the same address. As Matt2048 says, this is cryptographically negligible, assuming perfectly equiprobable distribution.
If someone else was to generate an address, they'd have to check whether there are any Monero on it though, and that isn't free. It can take about 20 minutes to scan the blockchain for a new address. ...
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 public address is basically your public spendkey and public viewkey. When you provide your public address to someone, they use the public spendkey and public viewkey to create outputs which only your private viewkey will identify as belonging to it and only your private spendkey will be able to spend.
Here's a partial quote from a reddit thread by core ...
Both the official CLI and GUI will allow you to restore a wallet from keys. In order to import a wallet from keys you need (i) the private spend key, (ii) the private view key, and (iii) the public address. Note that in the current implementation the private spend key is deterministic. Thus, if you only have the private spend key, you can easily "derive" the ...
For now, the are two used formats: standard (95 characters long) and integrated (106 characters long).
Subaddresses are a new type, but differ from standard addresses only by their prefix, so are also 95 characters long.
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 ...
A monero address includes a 32 bit checksum, so assuming the checksum is randomly distributed over the whole space, you get one match over about 4 billion, or 0.000000023283% chance of the checksum matching by pure chance.
However, all 95 character strings do not represent a valid address in the first place, so a failure to decode as base58 will also get an ...
Can someone please explain the technical method by which this can be completed successfully?
The range proof requires generating a lot of random values in the process. Nothing would change security-wise if that data was not entirely random and carried some encrypted payload instead.
What are the advantages of using this method over the current txextra ...
No. The 2 keys from which the address is made are 256-bits each, and that's how it is. You can't put 2 cups of water in 1 cup. Not using "hex" but base58 for the encoding already made them shorter, but there's only so many letters in the alphabet. If you used a bigger alphabet it would make them shorter, but probably impractical.
That's almost right. Due to specifics of underlying elliptic cryptography, the biggest private key is l-1, where l is defined in the CN whitepaper as:
l = 2^252 + 27742317777372353535851937790883648493
Anything bigger than that will get wrapped around by performing mod l operation so you'll always end up with a private key below l.
Also, private view key ...
You can also go to https://duckduckgo.com, and type:
qr code 4xxxxxxxxxxxx
And it will show you a QR code for 4xxxxxxxxxxxxx. Replace that string whatever you want, Monero address or otherwise.
I recommend using monero:4xxxxxxxxx by the way, as this is the payment URI defined in http://monero.wikia.com/wiki/URI_formatting (and which is used by the GUI). ...
Using the Monero Core GUI, for which a beta was released on December 22nd 2016, it is also possible to display a QR-code on the "Receive" page:
It even allows to embed a payment ID, e.g. when scanned the above results in:
It is pertinent to note that these different addresses are still half identical, and thus two such addresses can be trivially known to be the same owner.
Onchain you would not be able to group these addresses together, but indeed, offchain you would be able to see it. The reason XMR will get subaddresses is to avoid offchain grouping. You'll be able to ...
Bytecoin's scheme is to create addresses which differ in their spend key, but not in their view key. In that way, they are able to scan incoming transactions once, using the shared view key, while being able to distinguish the provenance (assuming they assign one such key per possible sender).
I like this system, as it's pretty simple, very scalable, and ...
It'd be possible to do that, yes. Mnemonic word lists are made from arbitrary binary strings by repeated base58 conversions from constant sized chunks of those strings. The canonical example is 25 word seeds for private spend key for deterministic keys. The code for allowing mnemonics for arbitrary bitstrings doesn't exist in Monero at the moment, but it'd ...
What I'd like to do is have all these devices mine to a single address, without joining a pool. Is this possible?
You can use the start_mining <addr> monerod command for each miner and direct all mined XMR to a single address under your control.
Sending directly to an entry in the address book is not possible at the moment. In monero-wallet-cli, those entries can only be used via the address_book command. This is something that's not very hard add though, and might be a good first patch for a new contributor.
Subaddresses have now been merged but not yet included in a tagged release. If you build from master, you can use them with the CLI now.
GUI support is still being worked on. Anyone with Qt experienced is encouraged to help!
Depending on your reason for wanting to use more than one address, the account command may be a helpful option for you.