[XMR] Monero - A secure, private, untraceable cryptocurrency

[luigi1111]

I never had so much trouble with blockchain.info as I am having with mymonero.com
It gives you 13 words, then asks you to type them
so, I typed, clicked on a button, which resulted in a message:

<invalid spend key> and nothing else

What is this?

Did you misstype something? I always copy and paste it (lol).

[1714483496]

1714483496

[1714483496]

1714483496

[smooth]

Here's what I get from Wolfram for the birthday problem, so you definitely shouldn't be seeing this every generation attempt. The 13th word does count, not for entropy purposes, but assuming crc32 is random enough, it should appear with the same probabilities as the other 12 words positions.

It looks to me like the 13th word is always one of the others, which makes the checksum just a few bits. I don't know why MyMonero did it that way, maybe for ease of remembering (at the cost of possibly less reliability in catching errors).

Assuming that is correct, and according to your birthday calculation, you will get one duplicate (with the last one) 100% of the time, but two duplicates 1/21, which is fairly common too.

[luigi1111]

Here's what I get from Wolfram for the birthday problem, so you definitely shouldn't be seeing this every generation attempt. The 13th word does count, not for entropy purposes, but assuming crc32 is random enough, it should appear with the same probabilities as the other 12 words positions.

It looks to me like the 13th word is always one of the others, which makes the checksum just a few bits. I don't know why MyMonero did it that way, maybe for ease of remembering (at the cost of possibly less reliability in catching errors).

Assuming that is correct, and according to your birthday calculation, you will get one duplicate (with the last one) 100% of the time, but two duplicates 1/21, which is fairly common too.

Whoops, you are absolutely correct. I must have been blind on my test. Let me take a look at what it's doing...

The revised birthday problem (12 candidates) is 1/25, still quite likely (to get "3").

Edit: all clear now.

Edit2, explanation: the mnemonic code is the same for both MyMonero and regular Electrum-style accounts. It runs crc32 on the words shortened to their prefix (e.g., "films gutter whipped summon navy inmate waveform tonic physics bemused february hobby" becomes "filgutwhisumnavinmwavtonphybemfebhob"). It then takes the result modulo the number of words (12 or 24). The answer is the checksum index -- the word that is to be appended as the checksum.

Edit3: more Wolfram fun -- in a standard 24 word seed, the probability of a "collision" is about 1/6.
In reality these probabilities (1/6, 1/25) for a "3x" repeat aren't accurate, because the checksum must fall on the duplicate, which can only happen if a duplicate happens.
I think it should be 1/6*2/24 and 1/25*2/12, about 1.4% and .67% respectively.

[cAPSLOCK]

I am not sure that wallets that mymonero.com currently creates are safe against hacking.
Example: I tried five times to create a wallet, but in each case I got at least two out of 13 words being identical and in one case (out of 5) i got three identical words.
If it uses the dictionary and then randomizes, the chance of this happening is so miniscule as to be negligible.
In my opinion, it means that wallet creation does not work properly (at least at this moment).

My question to developers-why is this happening?

Checksum.

please explain how two words (or even three) out of 13 could be the same, hopefully with a bit more detail.

I appreciate the word please there, but I do not have the time right now to do the work to provide you with a good enough answer. 

[smooth]

In reality these probabilities (1/6, 1/25) for a "3x" repeat aren't accurate, because the checksum must fall on the duplicate, which can only happen if a duplicate happens.
I think it should be 1/6*2/24 and 1/25*2/12, about 1.4% and .67% respectively.

For a triple yes, but not for two doubles.

[kazuki49]

old but gold: http://www.pcpro.co.uk/news/385735/stallman-calls-for-truly-anonymous-alternative-to-bitcoin

"We must have an anonymous way to pay websites so that they can’t have the excuse that the only way to get any money is by advertising that tracks people. We know that if companies track people, then the NSA or GCHQ is going to look at that data, it’s going to be tracking people through these companies."

[GingerAle]

Adding the payment ID with checksum seems fairly simple. I went and created a test address just now:

Code:

Standard Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byMUKoz6m
Payment ID: feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed

Code:

Integrated Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byXSb563RKvyBgorjsFGwyx9gorjsFGwyx9gorjsFGwyx9TpPbbCy

What I did:

Instead of the standard hex format - ('12' network byte) + (public spend key 64 digits) + (public view key 64 digits) + (checksum 8 digits) - I stripped the checksum and appended the payment ID, then recalculated and appended the new checksum. This creates a 101 byte address instead of the standard 69 byte, and 139 "Public Address" characters vs 95 standard.

cnBase58 --> hex the above "Integrated Address" and you get (separated for clarity):

Code:

12 55a1e49673f5a8faa6ba4f942585695ceee5c7522496be6fc38d3f09905e3f8b ca6313deac11aff9a7241e7095863b0be3099d50d7a0cd11e0adbcf4990e64b5 feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed b1d0950e

The code just needs to check for length to determine the type. Alternatively, (I don't know what all the other cryptonotes are using) the network byte could be changed to 0x13 or something for the "Integrated Address".

I am going to increase my portion of the bounty to 200 XMR to whoever wants to implement this in the next 4 weeks.

That brings the total bounty to ~450 XMR. Any takers?

I'm still following this, but have been super busy the last few weeks with other stuff. I may claim this if I can find the time.

Dude you should totally post this to: https://forum.getmonero.org/7/open-tasks

I would posit to say that it has been "approved by the community" because no one was like "hell no, this is a horrible idea, get your integrated addresses out mah yard!!!"

[luigi1111]

In reality these probabilities (1/6, 1/25) for a "3x" repeat aren't accurate, because the checksum must fall on the duplicate, which can only happen if a duplicate happens.
I think it should be 1/6*2/24 and 1/25*2/12, about 1.4% and .67% respectively.

For a triple yes, but not for two doubles.

Wait, were we talking about two doubles? Two doubles should be less likely than a triple, due to the checksum word.

[luigi1111]

Adding the payment ID with checksum seems fairly simple. I went and created a test address just now:

Code:

Standard Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byMUKoz6m
Payment ID: feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed

Code:

Integrated Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byXSb563RKvyBgorjsFGwyx9gorjsFGwyx9gorjsFGwyx9TpPbbCy

What I did:

Instead of the standard hex format - ('12' network byte) + (public spend key 64 digits) + (public view key 64 digits) + (checksum 8 digits) - I stripped the checksum and appended the payment ID, then recalculated and appended the new checksum. This creates a 101 byte address instead of the standard 69 byte, and 139 "Public Address" characters vs 95 standard.

cnBase58 --> hex the above "Integrated Address" and you get (separated for clarity):

Code:

12 55a1e49673f5a8faa6ba4f942585695ceee5c7522496be6fc38d3f09905e3f8b ca6313deac11aff9a7241e7095863b0be3099d50d7a0cd11e0adbcf4990e64b5 feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed b1d0950e

The code just needs to check for length to determine the type. Alternatively, (I don't know what all the other cryptonotes are using) the network byte could be changed to 0x13 or something for the "Integrated Address".

I am going to increase my portion of the bounty to 200 XMR to whoever wants to implement this in the next 4 weeks.

That brings the total bounty to ~450 XMR. Any takers?

I'm still following this, but have been super busy the last few weeks with other stuff. I may claim this if I can find the time.

Dude you should totally post this to: https://forum.getmonero.org/7/open-tasks

I would posit to say that it has been "approved by the community" because no one was like "hell no, this is a horrible idea, get your integrated addresses out mah yard!!!"

You could show us how it's done.

Actually we need to find the ones who offered the bounty to ensure accuracy. Johnny Mnemonic, shitaifan2013, and pa off the top of my head are who I remember.

Edit: the "top of my head" appears incorrect or at least incomplete.

[Bassica]

Add another 50.

I also added 50. I think it's vital for the XMR-community to make merchant adoption easier. We need to get a little economy going!

Exchanges, services, merchants, gambling sites etc need to have as little bounderies as possible.

[Biodom]

1. Is there a problem with older browsers (like Safari 5.1.10) and mymonero.com?
When I tried that browser version, i get an invalid key prompt (with all private key prompts typed properly), but I was able to get a wallet on a newer Safari.
2. Second question: is it safe to login using something called public keys, consisting of three items (public address, view key and spend key) or it is better to use 13 private keys for login, as tedious as it is?
3. Do you need transaction ID every time you want to receive funds?
4. What items/keys do you need to send funds?

perhaps this sounds naive, but the system looks quite different in use comparing with bitcoin, so I would appreciate the answer to these questions.

[roosmaa]

I disagree that we need to do nothing while we work on something better (obviously one does not preclude the other at all).

There is no checksum now. The length and valid characters are checked but that's it. The exact same thing can still be checked if the format is changed, slightly to something like

Code:

Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em-e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac

Instead of

Code:

Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em

and use this payment ID

e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac

It is the exact same thing in terms of checksums, validation, etc. except that the second is far more likely to lead to people forgetting it or not understanding it, and also fits worse with the usual workflow of a btc-style coin where people generate new addresses for each customer/invoice/etc., and has a higher support burden. With the first method, you have have the exact same kind of button in an exchange wallet window that says "generate new address" and it can go ahead and generate a new address that happens to share the same prefix, instead of needing something different for "payment-id coins".

We're suffering this unnecessary mismatch from the usual model and confusion because the cryptonote/BCN guys didn't see the need for a payment ID at all in their earlier design at all and threw the payment ID on there later as an extra thing instead of including it in addresses (there are commits in their repo when they added it, so it is clear it was an added patch). If it were part of the original design I bet something more like the prefix-suffix syntax would have been used.

I noticed someone talking about the address + payment id topic a few weeks back, but didn’t really think about it. Now Bassica pinged me about it and got me thinking about it.

The reason why someone suggested the idea was to “fix” the problem of Bitcoin users not paying attention to the payment ID field and making deposits the recipient cannot match, if I remember correctly. (Didn’t find the original post or the source of the idea, so it might not be correct.)

I agree that the amount of data the users currently have to insert is close to insane, but I don’t think stuffing the extra data into the actual destination address will make it better.

Instead it will make the address technically more complex (instead of 2 bits of information it would be storing potentially 3). Also one has to remember, if you introduce such feature you can pretty much never remove it.

From the technical side (of how payment ID is implemented) such solution would present user experience nightmares. Currently the payment ID is associated with the whole transaction, not the destination. If we had addresses which included the payment ID we would soon get users who would want to pay to several of those addresses, but since this is technically not possible we will forbid that. Now if the user did not care about the payment ID in one of the addresses there would be no easy way to just throw the payment ID out of the address.

The only “good” thing about the proposal is that the payment ID gets checksummed. But considering the amount of data users currently have to enter already, I don’t think it’s feasible to think that anyone does it by hand - thus the importance of checksum on that data diminishes.

So lets think of the original problem and if this truly is the solution.

In Bitcoin when users deposit money the have to use unique addresses. This is due to just Bitcoin limitations. In traditional banking when paying your phone bill you always have to fill in the reference field as well. So we can safely say that it’s just a bad habit that users picked up from Bitcoin that they expect a unique “account” number to deposit their money into.

Lets think about how users can pay on a website.

• Using a mobile wallet. Entering the address manually is not an option. User friendly options for mobile is QR code. They can embed the payment ID in it without changing anything in the Monero address format. OpenAlias can be used as a fallback.
• Using a desktop wallet. In this case the desktop wallet should install some URI handler, which would allow the user to just click a link on the payment page which would open their wallet. Again, this URI can include the payment ID, thus no need for any changes in the Monero address format. OpenAlias can again be used as a fallback.
• Using a command line wallet. The website should just display the whole command for simplewallet users, which they can copy-paste into the terminal. But lets be honest nobody should expect non-technical Monero users to keep using simplewallet after a better alternative is out. Alternatively simplewallet could implement a new command to pay to payment URIs. That way users can “Copy link address” from web and paste it into simple wallet.

None of those use-cases could justify creating a new Monero account address format.

What responsible wallets could also do, to educate users about the “reference field” (payment IDs), is to prompt the user if they really want to leave the payment ID field empty. That way the users at least confirm that they know what they’re doing if they transfer money with an empty payment id.

Currently there are 3 (?) Monero wallets: simplewallet, MoneroX and MyMonero. One command line wallet and two friendly looking wallets. The simplest short-term fix until the URI formats are worked out, would be to show the whole simplewallet transfer command and for MoneroX and MyMonero to confirm empty payment ID from users.

Long story short: if someone does implement the address+payment ID in one address in the format it has been proposed I would be against it. However, I would fully support working out a URI scheme (think BIP21) which could be used to pay a single entity (ie help merchants to receive payments with correct IDs and cut down on support queries).

[luigi1111]

1. Is there a problem with older browsers (like Safari 5.1.10) and mymonero.com?
When I tried that browser version, i get an invalid key prompt (with all private key prompts typed properly), but I was able to get a wallet on a newer Safari.
2. Second question: is it safe to login using something called public keys, consisting of three items (public address, view key and spend key) or it is better to use 13 private keys for login, as tedious as it is?
3. Do you need transaction ID every time you want to receive funds?
4. What items/keys do you need to send funds?

perhaps this sounds naive, but the system looks quite different in use comparing with bitcoin, so I would appreciate the answer to these questions.

Glad to help.

1. Do not know off hand (someone else [fluffypony] may, so not going to look into it right now)
2. Either method is equally safe, IMO. Revealing either one to a third party means they can steal your funds. Seed is easier (though longer if manually typing) in that it's just one text box (for copy/paste purposes).
3. For receiving funds, it behaves very similarly to BTC. Give someone your address; they send funds to it. You don't need to "do" anything to receive them (verifying that you received a transaction is a different story).
4. Assuming you're logged into MyMonero already, you'll just need the receiver's public address to send them funds. If it's an exchange or other service, they'll probably provide you with a payment ID to use as well, so they can differentiate your transaction from other users'.

[luigi1111]

Thanks for your thoughts on this. I'm sure this will spark some discussion. I must confess I didn't think about it very much, and it's very possible I/we aren't tackling this the right way.

[fluffypony]

Long story short: if someone does implement the address+payment ID in one address in the format it has been proposed I would be against it. However, I would fully support working out a URI scheme (think BIP21) which could be used to pay a single entity (ie help merchants to receive payments with correct IDs and cut down on support queries).

We already have a defined URI format that has been implemented in MoneroX, MyMonero, and others: http://monero.wikia.com/wiki/URI_formatting

The issue is that a URI alone doesn't fix it. Electrum has supported Bitcoin URIs since forever, but due to a py2app bug they don't work on OS X anymore. We're replacing it with cz_freeze to resolve the issue, but that's a ways away. Also it's easy to cut and paste the address and amount into Electrum.

I think that there are 3 things we need to do, in order of importance:

1. Wallets should pop up a confirmation box if there's no payment ID
2. Ratify and implement stealth payment IDs (much shorter), can be expressed in both serialised and non-serialised formats
3. Extend OpenAlias to support dynamic requests (I have some ideas around this that I'll hopefully flesh out with ThomasV from Electrum when I'm back in Berlin this coming weekend)

[Biodom]

For clarification, if we're suggesting to users what files are critical for backups, it's these, correct?

wallet.bin
wallet.bin.address.txt
wallet.bin.keys

All of the others files can be reconstructed, but the wallet* files are the most important?

You only need the .keys file, everything else can be discarded.

Also the .keys file doesn't change with ongoing use, and is encrypted with your wallet password, so you only need to back it up when you create the wallet:)

is there a simple path to download .keys file from mymonero wallet using web gui?
thanks

[Johnny Mnemonic]

I noticed someone talking about the address + payment id topic a few weeks back, but didn’t really think about it. Now Bassica pinged me about it and got me thinking about it.

The reason why someone suggested the idea was to “fix” the problem of Bitcoin users not paying attention to the payment ID field and making deposits the recipient cannot match, if I remember correctly. (Didn’t find the original post or the source of the idea, so it might not be correct.)

I agree that the amount of data the users currently have to insert is close to insane, but I don’t think stuffing the extra data into the actual destination address will make it better.

Instead it will make the address technically more complex (instead of 2 bits of information it would be storing potentially 3). Also one has to remember, if you introduce such feature you can pretty much never remove it.

From the technical side (of how payment ID is implemented) such solution would present user experience nightmares. Currently the payment ID is associated with the whole transaction, not the destination. If we had addresses which included the payment ID we would soon get users who would want to pay to several of those addresses, but since this is technically not possible we will forbid that. Now if the user did not care about the payment ID in one of the addresses there would be no easy way to just throw the payment ID out of the address.

The only “good” thing about the proposal is that the payment ID gets checksummed. But considering the amount of data users currently have to enter already, I don’t think it’s feasible to think that anyone does it by hand - thus the importance of checksum on that data diminishes.

So lets think of the original problem and if this truly is the solution.

In Bitcoin when users deposit money the have to use unique addresses. This is due to just Bitcoin limitations. In traditional banking when paying your phone bill you always have to fill in the reference field as well. So we can safely say that it’s just a bad habit that users picked up from Bitcoin that they expect a unique “account” number to deposit their money into.

Lets think about how users can pay on a website.

• Using a mobile wallet. Entering the address manually is not an option. User friendly options for mobile is QR code. They can embed the payment ID in it without changing anything in the Monero address format. OpenAlias can be used as a fallback.
• Using a desktop wallet. In this case the desktop wallet should install some URI handler, which would allow the user to just click a link on the payment page which would open their wallet. Again, this URI can include the payment ID, thus no need for any changes in the Monero address format. OpenAlias can again be used as a fallback.
• Using a command line wallet. The website should just display the whole command for simplewallet users, which they can copy-paste into the terminal. But lets be honest nobody should expect non-technical Monero users to keep using simplewallet after a better alternative is out. Alternatively simplewallet could implement a new command to pay to payment URIs. That way users can “Copy link address” from web and paste it into simple wallet.

None of those use-cases could justify creating a new Monero account address format.

What responsible wallets could also do, to educate users about the “reference field” (payment IDs), is to prompt the user if they really want to leave the payment ID field empty. That way the users at least confirm that they know what they’re doing if they transfer money with an empty payment id.

Currently there are 3 (?) Monero wallets: simplewallet, MoneroX and MyMonero. One command line wallet and two friendly looking wallets. The simplest short-term fix until the URI formats are worked out, would be to show the whole simplewallet transfer command and for MoneroX and MyMonero to confirm empty payment ID from users.

Long story short: if someone does implement the address+payment ID in one address in the format it has been proposed I would be against it. However, I would fully support working out a URI scheme (think BIP21) which could be used to pay a single entity (ie help merchants to receive payments with correct IDs and cut down on support queries).

I disagree with you for a number of reasons:

0) Traditional banking should not be a consideration as we are not trying to mimic the archaic processes of traditional banking.

1) Users copy-paste addresses anyway, and will probably use QR codes in the future, so the amount of data required is somewhat meaningless.

2) It's the user's responsibility to pay the merchant, not to organize their books. Pay IDs are a merchant responsibility. This issue has less to do with people being used to Bitcoin's workflow and more to do with common sense. Bitcoin's "bad habit" ultimately creates a better experience for the end user.

Usability dictates process. There is a seperation of concern between making a payment and handling a payment, and special needs on behalf of the merchant (in the form of payment ID) should not require additional brain power from the user.

[GingerAle]

I noticed someone talking about the address + payment id topic a few weeks back, but didn’t really think about it. Now Bassica pinged me about it and got me thinking about it.
.....

What responsible wallets could also do, to educate users about the “reference field” (payment IDs), is to prompt the user if they really want to leave the payment ID field empty. That way the users at least confirm that they know what they’re doing if they transfer money with an empty payment id.

......

Indeed, I proposed the same thing (and I think its actually an open issue in github), and I even forked monero to insert an if/then in the simplewallet code. Of course that could take forever for me to do.

I disagree with you for a number of reasons:

0) Traditional banking should not be a consideration as we are not trying to mimic the archaic processes of traditional banking.

1) Users copy-paste addresses anyway, and will probably use QR codes in the future, so the amount of data required is somewhat meaningless.

2) It's the user's responsibility to pay the merchant, not to organize their books. Pay IDs are a merchant responsibility. This issue has less to do with people being used to Bitcoin's workflow and more to do with common sense. Bitcoin's "bad habit" ultimately creates a better experience for the end user.

Usability dictates process. There is a seperation of concern between making a payment and handling a payment, and special needs on behalf of the merchant (in the form of payment ID) should not require additional brain power from the user.

As roosma was pointing out, and what you mention in point 2), it really depends on what the end use case is actually like - in most cases, its going to be where a transaction command is created by the merchant, the command is transferred to the user, the user confirms, and then executes the transaction.

So I tend to agree that serializing the address + payment ID overcomplicates the issue. In the meantime, during these growing pains, I think the available wallets should be "dumbed down" to recognize that 90% of users are coming to Monero from Bitcoin, and the other 10% are the aliens that invented Cryptonote. And so the wallet should go "hey your sending money into the void, do you want to add a payment ID?"

One of these days I'll work on the "noob wallet"

[Biodom]

1. Is there a problem with older browsers (like Safari 5.1.10) and mymonero.com?
When I tried that browser version, i get an invalid key prompt (with all private key prompts typed properly), but I was able to get a wallet on a newer Safari.
2. Second question: is it safe to login using something called public keys, consisting of three items (public address, view key and spend key) or it is better to use 13 private keys for login, as tedious as it is?
3. Do you need transaction ID every time you want to receive funds?
4. What items/keys do you need to send funds?

perhaps this sounds naive, but the system looks quite different in use comparing with bitcoin, so I would appreciate the answer to these questions.

Glad to help.

1. Do not know off hand (someone else [fluffypony] may, so not going to look into it right now)
2. Either method is equally safe, IMO. Revealing either one to a third party means they can steal your funds. Seed is easier (though longer if manually typing) in that it's just one text box (for copy/paste purposes).
3. For receiving funds, it behaves very similarly to BTC. Give someone your address; they send funds to it. You don't need to "do" anything to receive them (verifying that you received a transaction is a different story).
4. Assuming you're logged into MyMonero already, you'll just need the receiver's public address to send them funds. If it's an exchange or other service, they'll probably provide you with a payment ID to use as well, so they can differentiate your transaction from other users'.

Great, thanks

[wpalczynski]

Update!!

Well I lost it all. My hard died on me. I was able to sync with bitmonerod (thanks for the help by the way). However, my .keys files went down with the hard drive... 534 Monero's!! almost a year worth of mining down the drain.

Well, i still have 1.5 KH/s worth of mining power. Back to the drawing board....

Word of caution to all - BACKUP/SAVE your stuff! Don't be me!!!

Sorry to hear that.

Just wanna give the following tip.

Depending on the drive, and if it is a mechanical problem, SOMETIMES turning the drive upside down gives you enough access time to get some files out.

I also read that getting it really cold (freezer) and then copying files quickly works for some people.  Sounds crazy but might be worth a try.  If monero ever gains a lot of value paying 2-3k for recovery will be a non issue.