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

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

Monero will become something beautiful within the next year 

I guess I missed it. Thanks.

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.

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.

Read the last two Missives:

https://bitcointalksearch.org/topic/m.8388985
https://bitcointalksearch.org/topic/m.8388993

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: viewkey: e422831985c9205238ef84daf6805526c14d96fd7b059fe68c7ab98e495e5703

BTC:
Monero Community Hall of Fame

When will we see a final GUI release?

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.

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.


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.

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.

I think favorites is okay.


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.


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.

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 [email protected] 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).


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.

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://bitcointalksearch.org/topic/petitioning-cryptsy-btc-e-and-others-for-moneroxmr-731365

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

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

Rejoice, we made the right choice.

No, that's a separate effort. The 'official' one is still a work-in-progress and isn't up on github yet.

Philippines here..the site is good..using firefox here

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

1) Wallet is not resident on my local PC or other computing device
( this is huge as I don't have to worry about hard drive crashes/
local viruses stealing coins/ lost wallet.dat files/ me making mistakes etc etc

2) the wallet/client features  a 'one click' download and self extraction process
for intial setup and periodic upgrades/updates ( see nxtra.org )

3) All security features I've come across with crypto are focused on thwarting
access to one's wallet/account .. BUT .. and this is key ... nothing ( that I've seen ) to
authorize a "withdrawal" before it occurs .. ie If someone successfully hacks your
wallet/account the 'deed is done' and your coins are gone .. That 'withdrawal
authorization' step needs to be there ( from within the wallet/account )

If you technical types/developers can produce a wallet/account that's as
intuitive to use as the typical online brokerage  account or online banking
account that most of my contemporaries are familiar with ..
Then that coin wins ..

Thanks for listening ..

Triff ..

Its nice to see with all the rest of the crypto slump going.

I've made a couple little lucky trades in and out of these big buys...  I love action.