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

[sammy007]

Yesterday I watched the Fireside Chat, patiently waiting user-friendly GUI. Account term is more reasonable. You know Andreas Antonopoulos also don't like wallet term because it's confusing, he sees Bitcoin Core is like key-chain with all the private keys on it. I support "account", non-crypto environment can understand it better.

he really does says that, and makes sense because its not a wallet, you only hold the keys and the coins are in the blockchain... its seems xmr is giving another small but remarkable step in the right direction.

question: will the new wallet give an option to recover/import old wallets (before the wallet seed being implemented)

thank you monero team, amazing job!

How you can recover wallet without seed? It's impossible. Only if you have *.keys file.

[Jojatekok]

Yesterday I watched the Fireside Chat, patiently waiting user-friendly GUI. Account term is more reasonable. You know Andreas Antonopoulos also don't like wallet term because it's confusing, he sees Bitcoin Core is like key-chain with all the private keys on it. I support "account", non-crypto environment can understand it better.

he really does says that, and makes sense because its not a wallet, you only hold the keys and the coins are in the blockchain... its seems xmr is giving another small but remarkable step in the right direction.

question: will the new wallet give an option to recover/import old wallets (before the wallet seed being implemented)

thank you monero team, amazing job!

How you can recover wallet without seed? It's impossible. Only if you have *.keys file.

You may use the 'query_keys' JSON RPC command with the 'key_type' parameter of 'mnemonic' (I'm not sure whether it's included on the stable branch yet).

[thefunkybits]

XMR wallet looking thin?

Fear not! We are giving away 0.4 XMR for anyone who joins our twitter campaign to cryptsy, btce etc...

Please check the official thread for more info - https://bitcointalk.org/index.php?topic=731365.0

[fluffypony]

Lots of really good discussion about ripping out old terminology and replacing it with more intuitive and natural terms:)

There may be some value in retaining "address", as "address book" is a familiar concept for having a list of thing-I-remember (name) linked to thing-I-don't-remember (address), and "email address" is a familiar concept as a unique destination. If we replace address with account number, what do we call "Address Book"? I checked on my online banking, and the equivalent they have are "beneficiaries" in a "favourites" list, which I suppose is ok (although I've never been fond of "beneficiaries"..."recipients" maybe?) I'm not averse to dropping "address", as long as we can find a convention that fits.

One additional thing to consider: we are looking at ways of packing the payment ID into the "address" so that there are no longer issues with it being a separate thing that people forget. In this regard alone I lean towards address rather account number, because with a bank you pay into a person's single account number and allocation is manual/semi-automated, whereas with this you'd pay into seemingly-unique "addresses". Conceptually I would think this is somewhat similar to Gmail's functionality where you can receive email to name+description@gmail.com and it tags them with the bit after the +.

I think the 24 word "seed" is fine as a term, since it conveys the sense of "thing that everything else grows from" which underscores its importance, else we should call it a 24 word "key"? We will have additional formats that can be used to store your seed, such as a password-encrypted, base58-armoured version. Given that the use of stealth addresses removes the need to have multiple addresses in your wallet (and thus multiple privkeys) we can use the term "seed" or "key" comfortably (I have no preference between the two).

I think the wallet/account MUST be "familiar and easy to use"  ..
The simpler the better ..
I'm in that "wider population non-technical user" demographic ..
I'm in my 60's, somewhat computer literate, willing to try and learn  ..

That said, the "key" imho to mass adoption of any crypto is going to
be 100% on the ease of useablility/security/functinality of the wallet/account ..

Please consider the NXT brain wallet as a potential wallet/account to model after ..
It has several attractive features ..

A brain wallet is a terribly bad idea, not in and of itself, but because people are terribly bad at setting secure passphrases. Even a seemingly safe, single line from a very obscure Afrikaans poem got someone's brainwallet hacked and 4 BTC taken from it. It doesn't matter how much we educate, people are simply not going to use secure passphrases. If we enforce certain things automatically (say, 25 char minimum length, automated Google search must return no results, must not exist in previously known password caches) we are not only compromising our users by sending their secure password out to check (thus exposing it), but we are raising the barrier to entry to a point that is high enough to irritate newcomers and cause them to walk away in frustration.

The 24 word seed is sufficient for you to use Monero on any computer, and we can definitely look at ways of having a much shorter, password-encrypted base58 token in future.

[smooth]

Lots of really good discussion about ripping out old terminology and replacing it with more intuitive and natural terms:)

There may be some value in retaining "address", as "address book" is a familiar concept for having a list of thing-I-remember (name) linked to thing-I-don't-remember (address), and "email address" is a familiar concept as a unique destination. If we replace address with account number, what do we call "Address Book"? I checked on my online banking, and the equivalent they have are "beneficiaries" in a "favourites" list, which I suppose is ok (although I've never been fond of "beneficiaries"..."recipients" maybe?) I'm not averse to dropping "address", as long as we can find a convention that fits.

I think favorites is okay.

One additional thing to consider: we are looking at ways of packing the payment ID into the "address" so that there are no longer issues with it being a separate thing that people forget.

Doesn't this imply reusing payment ID's which is kind of bad? I think we need improvements to the usage model here. Ultimately people can view their exchange account as having an "account number" even if behind the scenes that turns into something else such as asking the user for a payment ID every time you use it (similar to current usage without reusing payment IDs), or automatically requesting one with some protocol (better).

Alternately the protocol could be improved to encrypt the payment IDs in transactions in which case they could be safely reused.

I think the 24 word "seed" is fine as a term, since it conveys the sense of "thing that everything else grows from" which underscores its importance, else we should call it a 24 word "key"? We will have additional formats that can be used to store your seed, such as a password-encrypted, base58-armoured version. Given that the use of stealth addresses removes the need to have multiple addresses in your wallet (and thus multiple privkeys) we can use the term "seed" or "key" comfortably (I have no preference between the two).

The basic user can certainly get away with one private key (i.e. address/account/whatever) but more advanced users are going to want multiple adresses/accounts/etc.

In summary I think account number is good. There can be a special type of account that involves using payment IDs in some manner.

[fluffypony]

Doesn't this imply reusing payment ID's which is kind of bad? I think we need improvements to the usage model here. Ultimately people can view their exchange account as having an "account number" even if behind the scenes that turns into something else such as asking the user for a payment ID every time you use it (similar to current usage without reusing payment IDs), or automatically requesting one with some protocol (better).

Alternately the protocol could be improved to encrypt the payment IDs in transactions in which case they could be safely reused.

Requesting one with a protocol is a problem, the daemon shouldn't touch out via non-p2p channels except for certain convenience features that a paranoid user can disable. Using something like that also makes offline rawtx's that much harder to make.

I'd argue for a smaller payment ID set than the current huge one - maybe as low as 10k possible payment IDs per wallet. The more payment ID collision there is in the blockchain the more useless it is as a metric.

The only alternative off the top of my head is to have a stealth payment ID. Following the parlance in the whitepaper (section 4.3), Bob would give Alice his public key (A, B, C) where C is the public ec-key of (c), the private ec-key that is the payment ID, and is packed into the address. The one-time public key computed by Alice by generating a random r ∈ [1,l−1] and then computing the public key as P = H_s(rA)G+B. Alice then generates a visible payment ID (that is sent in tx_extra) by computing I = H_s(rC)G. Bob identifies his transactions by computing P′ = H_s(aR)G + B (he knows R since Alice has packed R = rG into the transaction) and matching them against every passing transaction. Upon identifying a transaction, Bob is able to then determine the recipient by taking his set of locally generated payment IDs (the method by which he computes these, whether deterministic or random, is irrelevant, and the transaction is guaranteed to have a payment ID as the address given to Alice contained one) by computing I′ = H_s(cR) (since cR = crG = rC and I′ = I). Then again, I'm no mathematician and could be reaching with this.

[smooth]

Doesn't this imply reusing payment ID's which is kind of bad? I think we need improvements to the usage model here. Ultimately people can view their exchange account as having an "account number" even if behind the scenes that turns into something else such as asking the user for a payment ID every time you use it (similar to current usage without reusing payment IDs), or automatically requesting one with some protocol (better).

Alternately the protocol could be improved to encrypt the payment IDs in transactions in which case they could be safely reused.

Requesting one with a protocol is a problem, the daemon shouldn't touch out via non-p2p channels except for certain convenience features that a paranoid user can disable. Using something like that also makes offline rawtx's that much harder to make.

It is a convenience feature: You don't have to type in (or copy-paste, etc.) the payment ID that the payee gives you. If you want to be all paranoid about it, turn the feature off and type it in.

I'd argue for a smaller payment ID set than the current huge one - maybe as low as 10k possible payment IDs per wallet. The more payment ID collision there is in the blockchain the more useless it is as a metric.

10k is still a lot and this is 10k per payee, which means you have unlinkable payments only for the largest of merchants, because smaller merchants won't have <10k customers and every payment ID will uniquely identify a customer (unless they are not reused). Never mind. Obviously if the payment addresses are unlinkable then it would be 10k globally, so that isn't bad. Or maybe even a much smaller number.

As far as the stealth stuff, I think once you create a one-time public key you can just use that to encrypt the payment ID (decryptable by recipient since the recipient can extract the one-time private key), at which point it is okay to reuse them. There may be some tricky ninja crypto issues here, about whether certain key pairs can be used (or are safe to use) for encryption or just signing.

If you can unlinkably encrypt and therefore safely reuse payment IDs then the payment ID can be considered part of the account number. Something like BASEACCOUNT-SUBACCOUNT where SUBACCOUNT is what we now call payment ID.

[fluffypony]

10k is still a lot and this is 10k per payee, which means you have unlinkable payments only for the largest of merchants, because smaller merchants won't have <10k customers and every payment ID will uniquely identify a customer (unless they are not reused). Never mind. Obviously if the payment addresses are unlinkable then it would be 10k globally, so that isn't bad. Or maybe even a much smaller number.

As far as the stealth stuff, I think once you create a one-time public key you can just use that to encrypt the payment ID (decryptable by recipient since the recipient can extract the one-time private key), at which point it is okay to reuse them. There may be some tricky ninja crypto issues here, about whether certain key pairs can be used (or are safe to use) for encryption or just signing.

If you can unlinkably encrypt and therefore safely reuse payment IDs then the payment ID can be considered part of the account number. Something like BASEACCOUNT-SUBACCOUNT where SUBACCOUNT is what we now call payment ID.

Sorry yes - I mean dump the 64-char hex string and go for something that tops out at a reasonably sane amount, which will cause tons of collision on the blockchain over time. The stealth idea wouldn't require this, it would be unbound and sent as a hash because it's stealthed. Regardless of which route we take, packing it in with the account number is a necessity, even if this means the account number grows by a number of base58 characters.

[obocaman]

When will we see a final GUI release?

[fluffypony]

When will we see a final GUI release?

Read the last two Missives:

https://bitcointalk.org/index.php?topic=583449.msg8388985#msg8388985
https://bitcointalk.org/index.php?topic=583449.msg8388993#msg8388993

If anything is unclear, please ask:) If you'd like to speed up the effort we're able to put in to development, please consider donating:

Donations for general development

XMR:

Code:

46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em

viewkey: e422831985c9205238ef84daf6805526c14d96fd7b059fe68c7ab98e495e5703

BTC:

Code:

1FhnVJi2V1k4MqXm2nHoEbY5LV7FPai7bb

Monero Community Hall of Fame

[Anon136]

When will we see a final GUI release?

Read the last two Missives:

https://bitcointalk.org/index.php?topic=583449.msg8388985#msg8388985
https://bitcointalk.org/index.php?topic=583449.msg8388993#msg8388993

If anything is unclear, please ask:) If you'd like to speed up the effort we're able to put in to development, please consider donating:

Donations for general development

XMR:

Code:

46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em

viewkey: e422831985c9205238ef84daf6805526c14d96fd7b059fe68c7ab98e495e5703

BTC:

Code:

1FhnVJi2V1k4MqXm2nHoEbY5LV7FPai7bb

Monero Community Hall of Fame

If i'm remembering correctly, earlier you guys said that you didnt want to bring out a gui until you had solved the database stuff first because monero was not yet ready for the flood of users that would come with it. Now i see you guys talking about gui all the time and hardly ever about the database so im just wondering if something has changed. This is a big deal to me personally because I only have 2 gig's of ram. Im not sure if i even have access to my coins any more and if i do, not for long.

[smooth]

If i'm remembering correctly, earlier you guys said that you didnt want to bring out a gui until you had solved the database stuff first because monero was not yet ready for the flood of users that would come with it. Now i see you guys talking about gui all the time and hardly ever about the database so im just wondering if something has changed. This is a big deal to me personally because I only have 2 gig's of ram. Im not sure if i even have access to my coins any more and if i do, not for long.

The database work is well under way, and early performance tests with an external database are either under way or imminent. Isn't that mentioned in the missives?

If you have a 64 bit system you will be fine for a while despite the 2 GB of RAM. You might need a swap file and performance will suffer a bit but it will still work.

[Anon136]

If i'm remembering correctly, earlier you guys said that you didnt want to bring out a gui until you had solved the database stuff first because monero was not yet ready for the flood of users that would come with it. Now i see you guys talking about gui all the time and hardly ever about the database so im just wondering if something has changed. This is a big deal to me personally because I only have 2 gig's of ram. Im not sure if i even have access to my coins any more and if i do, not for long.

The database work is well under way, and early performance tests with an external database are either under way or imminent. Isn't that mentioned in the missives?

If you have a 64 bit system you will be fine for a while despite the 2 GB of RAM. You might need a swap file and performance will suffer a bit but it will still work.

I guess I missed it. Thanks.

[scroogeMcDuck]

Monero will become something beautiful within the next year 

[fluffypony]

If i'm remembering correctly, earlier you guys said that you didnt want to bring out a gui until you had solved the database stuff first because monero was not yet ready for the flood of users that would come with it. Now i see you guys talking about gui all the time and hardly ever about the database so im just wondering if something has changed. This is a big deal to me personally because I only have 2 gig's of ram. Im not sure if i even have access to my coins any more and if i do, not for long.

The database stuff will be done quite some time before a GUI is complete. Because we're cognisant of the amount of work involved in bring the GUI to fruition to the standards we expect, we have had no problem starting work on it sooner rather than later. By the time it's done all the other bits will be done;)

[Anon136]

If i'm remembering correctly, earlier you guys said that you didnt want to bring out a gui until you had solved the database stuff first because monero was not yet ready for the flood of users that would come with it. Now i see you guys talking about gui all the time and hardly ever about the database so im just wondering if something has changed. This is a big deal to me personally because I only have 2 gig's of ram. Im not sure if i even have access to my coins any more and if i do, not for long.

The database stuff will be done quite some time before a GUI is complete. Because we're cognisant of the amount of work involved in bring the GUI to fruition to the standards we expect, we have had no problem starting work on it sooner rather than later. By the time it's done all the other bits will be done;)

thanks

[aminorex]

Doesn't this imply reusing payment ID's which is kind of bad?

So is re-using addresses.  The same solution can be applied, in applicable cases:   generate a new one.
I.e., in some workflows it would be suitable to generate payment ids from a shared seed with an incrementing nonce.

[aminorex]

Regardless of which route we take, packing it in with the account number is a necessity, even if this means the account number grows by a number of base58 characters.

Unicode is everywhere now.  It would make base-2^20 possible, saving on string length.

This is a joke, by the way.  The reason why it is infeasible is that most people can't type these strings, or read them out loud.  It would bring new meaning to "view-only key".

[RentaMouse]

Most existing online payment systems I have seen include the option to include a payment "reference" or identifier, e.g. when making a transfer to a local business to pay an invoice I enter their bank account details and then the reference would be the invoice number so they can easily allocate the payment. I appreciate that these systems provide the recipient with additional information that can be used to identify a payment should the reference be omitted or incorrect, which Monero doesn't, but I also suspect that the problem may be more significant currently because the CLI wallet does not provide any visual reminder that a payment ID may be required. When a novice user is presented with a GUI wallet "send payment" window that clearly requests a payment ID (and possibly asks them to confirm if they dont enter one) I believe that it will become much less of a problem.

Might be something to experiment with when user testing the new GUI wallet/account, it may not be necessary to make changes to the payment system.

[krawallmining]

Ahh, now I'd like to get my hands on an Windows GUI build which doesn't require that exhausting qt procedure.