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

[Nekomata]

XMR is the future.

[1714801425]

1714801425

[1714801425]

1714801425

[1714801425]

1714801425

[krawallmining]

Could anybody explain a bit about the "history" of payment id?
It's optional for client to client transactions, but why are exchanges dependent on it? What's the purpose?

[jwinterm]

Could anybody explain a bit about the "history" of payment id?
It's optional for client to client transactions, but why are exchanges dependent on it? What's the purpose?

Exchanges usually only run one wallet. For btc and btc-clones, you have an account/address for each user of that wallet, so that's why everyone get's their own address for depositing funds. For monero simplewallet, there is only one address, it's not practical to have an instance of the wallet running for every user of the exchange. So, to get around this, they have everyone deposit to the same address, but give them each a unique payment id, so they can tell who deposited what funds.

[falskmyntaren]

this is my favorite pic

It's very good. Some humble tweak suggestions:

https://i.imgur.com/7KMdJel.jpg

Destination might be called "recipient"?

Payment ID is crucial if required, should not be last.

Privacy level *before* amount and SEND, to avoid accidental unsafe transactions.

Amount LAST when recipient and privacy are sent.

[fluffypony]

I think they should rename the Monero Missives to the Monero Massives because this looks like a great UI.

Can't wait to use it (on OSX). Hehe.

Edit:
I would like to be able to see the # of mixins on the slider where you choose how private to make the transaction.

That's in the works - we've just been debating it peripherally (for 2 weeks) so we get how it displays correct. For the most part, even a power user may not care about the actual value after a while, so we don't want the numerical amount to be too obtrusive (or too hidden;)

The continuum slider is cool.  And then a  mouse over context popup can give detail about the chosen level. (x-mixin, network yaya).  Personally I think the slider should be as granular (detented) as the actual privacy steps.

It will have complete granularity in integer steps up to a realistic top-end (no clue what, let's call it a mixin of 100 for argument's sake). If for any reason someone needs to use a mixin level beyond that top end they would have to create a manual tx or use the CLI / RPC tools. We want to provide a reasonable scope, but we also can't cater for edge cases. If it so happens in future that large block sizes are common, large tx sizes are common, blah blah, then increasing this top end is a trivial exercise that a power user can do in the source and compile on their own without even waiting for us to make the change:)

[fluffypony]

Destination might be called "recipient"?

Payment ID is crucial if required, should not be last.

Privacy level *before* amount and SEND, to avoid accidental unsafe transactions.

Amount LAST when recipient and privacy are sent.

Good stuff - I'll bounce this around and a bit with the UI designers. If for whatever reason we forget about it, then wait till the interface code is up on github and you'll be able to open an issue for this. The text is also very much "up for grabs" at this stage, we've been design focused and haven't touched the wording on anything besides the wallet -> account thing (which has a wider impact).

[fluffypony]

This looks fantastic guys! Are you targeting a beta for release or just releasing it when finished? If so when do you think we can get our hot little hands on it?

Once we've tightened the nuts and bolts on the interface (a few more weeks, donations dependent) we'll push the interface up to a project of its own on github so we can better manage all the translation efforts. Tangentially and simultaneously, the integration with Monero will start. Given the complexity of all of this, we may find that the interface is ready, the translations are ready, and the integration drags a little, but since the integration efforts there will be an ongoing and continuous it will be able to be tested by everyone. Eventually when things are more broadly tested, all features are done, and it is ready for prime time, we will have an official launch (totally with a launch party;)

[IntroVert]

Destination might be called "recipient"?

Payment ID is crucial if required, should not be last.

Privacy level *before* amount and SEND, to avoid accidental unsafe transactions.

Amount LAST when recipient and privacy are sent.

Good stuff - I'll bounce this around and a bit with the UI designers. If for whatever reason we forget about it, then wait till the interface code is up on github and you'll be able to open an issue for this. The text is also very much "up for grabs" at this stage, we've been design focused and haven't touched the wording on anything besides the wallet -> account thing (which has a wider impact).

Another thing you might consider is to switch the font sizes on locked and available balance. When sending money I would be interested in how much money are available for sending, and not how much are not available, hence the bigger font for the available. Alternatively, you can use a different color for the locked balance like orange, red, etc. to denote unavailability of funds.

[jlong187]

how's GPU mining compared to CPU mining for this coin?

[iourzzz]

Destination might be called "recipient"?

Payment ID is crucial if required, should not be last.

Privacy level *before* amount and SEND, to avoid accidental unsafe transactions.

Amount LAST when recipient and privacy are sent.

Good stuff - I'll bounce this around and a bit with the UI designers. If for whatever reason we forget about it, then wait till the interface code is up on github and you'll be able to open an issue for this. The text is also very much "up for grabs" at this stage, we've been design focused and haven't touched the wording on anything besides the wallet -> account thing (which has a wider impact).

Another thing you might consider is to switch the font sizes on locked and available balance. When sending money I would be interested in how much money are available for sending, and not how much are not available, hence the bigger font for the available. Alternatively, you can use a different color for the locked balance like orange, red, etc. to denote unavailability of funds.

Probably in addition to that it's more logical to move available balance on top of locked.

[fluffypony]

Another thing you might consider is to switch the font sizes on locked and available balance. When sending money I would be interested in how much money are available for sending, and not how much are not available, hence the bigger font for the available. Alternatively, you can use a different color for the locked balance like orange, red, etc. to denote unavailability of funds.

Probably in addition to that it's more logical to move available balance on top of locked.

This is something already changed in the next sprint, but didn't reflect in the one I showed off:)

[krawallmining]

Exchanges usually only run one wallet. For btc and btc-clones, you have an account/address for each user of that wallet, so that's why everyone get's their own address for depositing funds. For monero simplewallet, there is only one address, it's not practical to have an instance of the wallet running for every user of the exchange. So, to get around this, they have everyone deposit to the same address, but give them each a unique payment id, so they can tell who deposited what funds.

Ah, thx.

[Mumbles]

You guys did a fantastic job with the GUI wallet. A big step forward in usability and professionalism.

One comment on the "privacy level" display issue. I think that will confuse most users who are not crypto geeks. I would recommend hiding that in an advanced tab or settings somewhere and just use a good default value. The average person who sends money will not understand or want to worry about that, and in fact, it may make them feel nervous or unsure of what they are doing.

One of the things we've spent an inordinate amount of time is abstracting stuff away from simplewallet. This has resulted in us being able to build rpcwallet, which takes the rpc guts out of simplewallet and gives it a much more robust frame for automated environments.

The GUI will use the same libraries the daemon does, so it will provide the same underlying functionality without the need for a second instance of the daemon to run. This is NOT the right solution for mobile devices or even very low power devices. That said, the fundamentals that we're abstracting and working on now will allow a rich variety of interfaces to exist, all inheriting and using the same functionality without worrying about underlying application logic changes.

[fluffypony]

You guys did a fantastic job with the GUI wallet. A big step forward in usability and professionalism.

One comment on the "privacy level" display issue. I think that will confuse most users who are not crypto geeks. I would recommend hiding that in an advanced tab or settings somewhere and just use a good default value. The average person who sends money will not understand or want to worry about that, and in fact, it may make them feel nervous or unsure of what they are doing.

Don't you think this is a knowledge transfer / user education thing? I mean, after the first start wizard new users will see the tutorial screen (I'll show that off when completed), so before they see the privacy slider in the natural course of things they'll learn what it is.

Not showing the privacy slider effectively locks 90% of future transactions in at a single mixin (or even a random selection from a group), so this is something we need to keep loose so that the anonymityset isn't slightly reduced by a fixed mixin level.

[statdude]

Maybe dumb question, but what are the effects of higher vs lower mixins on

-blockchain size
-transaction speed

[xulescu]

Maybe dumb question, but what are the effects of higher vs lower mixins on

-blockchain size
-transaction speed

TX size grows linerly with mixin count. TX data is the bulk of the blockchain size, block headers being relatively negligible. TX speed is not affected. At this moment TX fees are not affected but that is likely to change in the future.

[fluffypony]

Maybe dumb question, but what are the effects of higher vs lower mixins on

-blockchain size
-transaction speed

blockchain size

The higher the mixin the greater the physical transaction size, so if everyone is using a mixin of 100 it would increase tx size (and thus block size) linearly with the mixin amount.

transaction speed

Zero impact. Unlike a coin that uses multiple stages of mixing, onion mixing, or CoinJoin (even with multiple mixing stages) a tx is the same speed whether it has a mixin of 2, 20, or 200.

[owlcatz]

how's GPU mining compared to CPU mining for this coin?

Great for AMD users, maybe not so much for nvidia users. I get around 650h/s with 2 AMD r9 270x's... Make about one xmr a day using claymores miner. (Is he rich yet lol?)

Edit - claymores miner only runs on winblows too.

[primer-]

how's GPU mining compared to CPU mining for this coin?

Great for AMD users, maybe not so much for nvidia users. I get around 650h/s with 2 AMD r9 270x's... Make about one xmr a day using claymores miner. (Is he rich yet lol?)

Edit - claymores miner only runs on winblows too.

1XMR/day will not cover electricity alone, why do you mine monero at a loss ?

[owlcatz]

how's GPU mining compared to CPU mining for this coin?

Great for AMD users, maybe not so much for nvidia users. I get around 650h/s with 2 AMD r9 270x's... Make about one xmr a day using claymores miner. (Is he rich yet lol?)

Edit - claymores miner only runs on winblows too.

1XMR/day will not cover electricity alone, why do you mine monero at a loss ?

Sorry i did not mention that my electricity is free right now.