Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 915. (Read 4671920 times)

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.

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"

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.

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

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)

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.

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'.

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).

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.

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.

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.

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

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!!!"

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

For a triple yes, but not for two doubles.

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. 

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.

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.

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

#2 is what we're looking at here for sure. I just created a test account and it had no matches.



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.

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.