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

Whats up with monerochain.info?  I just checked it and it still doesnt appear to be synchronized.  Are there any other sites such as that one?  What is the official one?

Thanks.

Roughly speaking it serves a similar sort of purpose to looking at payments to an address on a bitcoin block explorer. Since payments are unlinkable by default you can't tell which payments are going to a specific address in Monero, unless you have the view key. So it can be used to track payments to an address that is supposed to be public, such as a donation address. I don't think there is any software to actually do this yet though.

There are also some technical applications for it, such as being used by lightweight clients (so a remote server can find your incoming transactions and forward them to you without being able to steal your coins). There are no lightweight clients yet either.

So presently it serves no practical purpose but will be used in the future.

stupid question, what is the purpose of the view key?

The DB is a much smaller undertaking. The main reason it is taking as long as it is we are not only adding a database but also doing a lot of documenting and refactoring as we go. This will not only improve the database solution (which will be modular allowing different databases to be used in different deployment environments) but also improve the overall development effort going forward. When we forked we got a bunch of undocumented code that frankly is not really that great in a lot of ways. We are making it better at the core.

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

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.

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

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.

thanks

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.