Maybe dumb question, but what are the effects of higher vs lower mixins on
-blockchain size
-transaction speed
Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1565. (Read 4670622 times)
August 09, 2014, 04:43:16 PM
August 09, 2014, 04:37:31 PM
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 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.
August 09, 2014, 03:50:07 PM
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.
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.
August 09, 2014, 03:01:12 PM
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. August 09, 2014, 01:52:42 PM
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:)
August 09, 2014, 01:32:07 PM
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.
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.
August 09, 2014, 01:21:22 PM
how's GPU mining compared to CPU mining for this coin?
August 09, 2014, 01:19:58 PM
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.
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.
August 09, 2014, 01:07:55 PM
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;)
August 09, 2014, 01:05:04 PM
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.
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).
August 09, 2014, 01:02:20 PM
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.
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:)
August 09, 2014, 12:20:57 PM
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.
August 09, 2014, 11:23:12 AM
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?
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.
August 09, 2014, 11:18:35 AM
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?
It's optional for client to client transactions, but why are exchanges dependent on it? What's the purpose?
August 09, 2014, 11:00:55 AM
XMR is the future.
August 09, 2014, 10:39:53 AM
Why isn't Monero listed on cryptsy yet?
They added so many bad coins but not Monero?
I wanted to buy some just now and could not find it there.
They added so many bad coins but not Monero?
I wanted to buy some just now and could not find it there.
I was wondering the same thing when I first heard about Monero...it seems that XMR's unique code is making it hard for them to implement into the site. I'm sure they'll be adding it eventually, but until then they have lost my business to www.poloniex.com
I've been tweeting them about Monero - @cryptsy
EDIT: I've just started a twitter petition to Cryptsy for Monero, please join me! - https://bitcointalksearch.org/topic/petitioning-cryptsy-btc-e-and-others-for-moneroxmr-731365
August 09, 2014, 10:04:53 AM
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.
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.
August 09, 2014, 09:44:05 AM
Why isn't Monero listed on cryptsy yet?
They added so many bad coins but not Monero?
I wanted to buy some just now and could not find it there.
They added so many bad coins but not Monero?
I wanted to buy some just now and could not find it there.
August 09, 2014, 08:06:12 AM
How i can mine monero on linux/bamt with GPU?
Miners are listed in the first post of this thread.
August 09, 2014, 08:01:50 AM
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?
Jump to: