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

[osensei]

i use yam minerd xmr in centos,but "Error:no ..."Often,Cause abnormal program termination, and how to solve

Are you using a version compatible with your CPU?

Yam miner has a different binary for each CPU microarchitecture it supports (Sandy Bridge, Ivy Brige, Haswell, etc...). Make sure you are using the one built for your CPU, or try using the different binaries and see which one works (if any) and which performs faster.

You can download the latest version from https://mega.co.nz/#F!h0tkXSxZ!f62uoUXogkxQmP2xO8Ib-g , although some users have reported better performance/stability with previous versions. Here you have a previous one: ttps://mega.co.nz/#F!UlkU0RyR!E8n4CFkqVu0WoOnsJnQkSg

If none of them works, you can try using Wolf's miner from: https://github.com/wolf9466/cpuminer-multi

[1715216437]

1715216437

[1715216437]

1715216437

[1715216437]

1715216437

[1715216437]

1715216437

[smooth]

I have +200-1000 kh/s monero miners.
Is it better to mine solo with this hash power?
Can anyone tell me how to mine solo to only one wallet from many GPU's?

If you really meant KH/s (kilohashes/second), then you would be better off mining solo. To do that you would have to set up your own pool, which can be done by following the instructions on the README.md file from any of the open source pool forks which fluffypony already mentioned:

https://github.com/fancoder/cryptonote-universal-pool
https://github.com/sammy007/node-cryptonote-pool
https://github.com/perl5577/node-cryptonote-pool

If you meant H/s (hashes/second) and you want receive frequent payouts, then you should mine at a pool. You could still set up your own pool, but it could take several weeks to find a block depending on your luck.

And finally, if its KH/s and you still opt to mine at a pool, then it would be better for the network (and some would say that for you too) to mine at some of the smaller pools, and not one of the top.

He did say many GPUs so it can't be 200-1000 H/s. Either he's talking about a pretty big farm (several hundred GPUs) or he's confused but either way your advice was good. Also, visit the mining thread: https://bitcointalk.org/index.php?topic=653467.0

[arnuschky]

There is nothing we can do without dev's support and they just don't care... They should be all over this, pooling all unclaimed xmr into one big fund for the core team and other third-party contributors...

Frankly, I find the suggestion morally dubious. Those funds were sent to Poloniex to trade, that they cannot be linked to an account through human error does not free them up for us to take. Those funds belong to the people that sent them to Poloniex, and we have no way of knowing who they are or how important those funds are to those individuals.

If Poloniex choose to take some independent action and donate the funds we won't stop them (nor would we even know it was them who donated unless they tell us), but if we go kick up a storm, demanding the funds, what do we do if in 6 months time someone comes along and says "oh dear, those funds I thought were on Poloniex actually aren't!"

You're quick to accuse us of "passive problem solving", but if the alternative is borderline theft then I'd rather take the accusation of being passive.

I agree.

We at xmr.to are facing the same problem of course; even worse, we don't have any means to identify and contact users (which is, after all, the whole point of the exercise ) Thankfully, up to now, every time someone sent a transaction without a payment ID, they contacted us and claimed it. However, we discussed internally what we will do with unclaimed payments, and until now we did not see any option other than sitting on it. As already said, the money doesn't belong to us so we can only act as a custodian of our customer's funds.

Now, if the community wholeheartedly agrees on donating orphan funds after some time-out period to the devs, we might consider to amend our terms of service. However, I personally find this kind of blanked statement on customer funds morally borderline. Would be different if we could use an opt-in on an individual basis, but alas...

[generalizethis]

There is nothing we can do without dev's support and they just don't care... They should be all over this, pooling all unclaimed xmr into one big fund for the core team and other third-party contributors...

Frankly, I find the suggestion morally dubious. Those funds were sent to Poloniex to trade, that they cannot be linked to an account through human error does not free them up for us to take. Those funds belong to the people that sent them to Poloniex, and we have no way of knowing who they are or how important those funds are to those individuals.

If Poloniex choose to take some independent action and donate the funds we won't stop them (nor would we even know it was them who donated unless they tell us), but if we go kick up a storm, demanding the funds, what do we do if in 6 months time someone comes along and says "oh dear, those funds I thought were on Poloniex actually aren't!"

You're quick to accuse us of "passive problem solving", but if the alternative is borderline theft then I'd rather take the accusation of being passive.

I agree.

We at xmr.to are facing the same problem of course; even worse, we don't have any means to identify and contact users (which is, after all, the whole point of the exercise ) Thankfully, up to now, every time someone sent a transaction without a payment ID, they contacted us and claimed it. However, we discussed internally what we will do with unclaimed payments, and until now we did not see any option other than sitting on it. As already said, the money doesn't belong to us so we can only act as a custodian of our customer's funds.

Now, if the community wholeheartedly agrees on donating orphan funds after some time-out period to the devs, we might consider to amend our terms of service. However, I personally find this kind of blanked statement on customer funds morally borderline. Would be different if we could use an opt-in on an individual basis, but alas...

Playing devil's advocate:

Wouldn't it better to make code that fixes the problem than to create a communal solution that isn't 100% or can be abused? Say someone is in a car accident and left in a comma for two tears, is it ok to tell them, "Sorry your 1000xmr were donated to the Monero dev fund because you hadn't claimed them within 12 months" ? Isn't there a way to code around this problem? I've also read on the Polo troll box complaints about the payment id and some claiming to have lost their funds because of it--maybe this is a good time to get ahead of it and keep potential FUDstorms to a minimum.

[Johnny Mnemonic]

There have been talks in the past about the ability to simply append the payment ID to the address when sending a transaction. If that can be done in the future, then the merchant/receiver just needs to generate a unique payment ID of their own and append it to the receiving address they display to the user.

[sphericon]

There have been talks in the past about the ability to simply append the payment ID to the address when sending a transaction. If that can be done in the future, then the merchant/receiver just needs to generate a unique payment ID of their own and append it to the receiving address they display to the user.

Thinking about this, why wouldn't a merchant like polo simply make payment ID a required field?  I don't think it is necessarily monero's problem if they offer multiple ways to pay (anonymous or not) and the merchant simply decides to not require the portion that makes the transaction trackable?  For a centralized exchange that needs exact accounting of all transactions, this seems like bad implementation on their part (and everyone else's part who needs to keep track of user transactions).

[psterryl]

Thinking about this, why wouldn't a merchant like polo simply make payment ID a required field?  I don't think it is necessarily monero's problem if they offer multiple ways to pay (anonymous or not) and the merchant simply decides to not require the portion that makes the transaction trackable?  For a centralized exchange that needs exact accounting of all transactions, this seems like bad implementation on their part (and everyone else's part who needs to keep track of user transactions).

How can you make payment ID a required field on transactions that people send to you? It's not like you can return coins to the original address if they arrive without a payment ID (thanks to the deniability afforded by ring-sigs). The only way to make payment IDs a required field would be to maintain a list of exchange wallet addresses (which has the downside of needing to be updated any time an address changes or a new exchange opens) and then make the IDs required on all pool/wallet transactions to those addresses.

No doubt some people would still mess it up and put the wrong ID in, however.

[generalizethis]

Thinking about this, why wouldn't a merchant like polo simply make payment ID a required field?  I don't think it is necessarily monero's problem if they offer multiple ways to pay (anonymous or not) and the merchant simply decides to not require the portion that makes the transaction trackable?  For a centralized exchange that needs exact accounting of all transactions, this seems like bad implementation on their part (and everyone else's part who needs to keep track of user transactions).

How can you make payment ID a required field on transactions that people send to you? It's not like you can return coins to the original address if they arrive without a payment ID (thanks to the deniability afforded by ring-sigs). The only way to make payment IDs a required field would be to maintain a list of exchange wallet addresses (which has the downside of needing to be updated any time an address changes or a new exchange opens) and then make the IDs required on all pool/wallet transactions to those addresses.

No doubt some people would still mess it up and put the wrong ID in, however.

Perhaps a warning message if the Payment ID isn't filled? Seems that is sufficient due diligence on their part and would familiarize the process to the uninitiated. I did this my first time--just ignorance--and was worried until the support team fixed it.

[generalizethis]

A couple of good questions--too technical for me to answer with precision:

Step 3 seems unnecessary. AFAIK cryptonote coins achieve this same effect by including old transactions with new transactions in the ring signature.  Steps 1 and 2 also are covered by ring signature coins. Step 4 might always be up to the sender--though zerocash or quantum money might be able to fix this in the future (not sure as most of this work is still fringe).

I just don't know enough about ring signatures - I wish someone would explain them to me.

My impression of ring signatures is that only a limited number of people can participate in each ring signature (I'm not sure of how it is arranged which ones participate). For example, in one instance when I tried only 10 could participate, so the probability is 1/10 that a member of the ring did the transaction, which is far less anonymous than the theoretical 1/N, where N=all users of the coin.

Also, I'm not sure to what extent one can analyze standard denominations and sums of them etc with Cryptonote coins. One problem is that some transaction sizes (small or large) might be less common than others, reducing anonymity. Is the transaction size hidden in a ring signature?

Also, when ring signatures includes old transactions, can this be arbitrarily far back in time?

https://bitcointalk.org/index.php?topic=1011959.0

[arnuschky]

Playing devil's advocate:

Wouldn't it better to make code that fixes the problem than to create a communal solution that isn't 100% or can be abused? Say someone is in a car accident and left in a comma for two tears, is it ok to tell them, "Sorry your 1000xmr were donated to the Monero dev fund because you hadn't claimed them within 12 months" ? Isn't there a way to code around this problem? I've also read on the Polo troll box complaints about the payment id and some claiming to have lost their funds because of it--maybe this is a good time to get ahead of it and keep potential FUDstorms to a minimum.

Well, we're doing what we can. We provide a QR-code, a link to click on, and a copy&paste preformatted line for simplewallet that all include that the payment ID for an xmr.to order. How much more can we do from our side?

On the side of wallets, matters could be slightly improved. With payment IDs being of almost the same importance in merchant payments as the address and amount, maybe wallets shouldn't allow to send funds without a payment ID except after asking for confirmation.

However, people will still get things wrong. What we also see on xmr.to is that people mix up their copy&pastes, thinking they did add the correct payment ID but pasted the wrong one etc.

A solution for that would be to provide a simple visual checksum to the user. One could hash the three necessary parameters (address, amount, payment id) and show this to the user, either graphically or in writing. For example, the user's wallet and the merchants website could all perform the following check:

Code:

SHA256(address;amount;paymentid)

and show the last four letters of the hash in large font to the user. Then it's easy to spot if your payment is somewhere wrong. Of course, this needs to be standardized across wallets and service providers in order to make any sense.

[dewdeded]

arnuschky: You are doing very good work, thank you.

[5w00p]

IS MONERO BROKEN?

I just looked on chainradar.com and it can tell from which transaction the input is, no matter of the mixin count?

When did this happen? Can't seem to find any thread on this.

Ummm, no.

I am quite sure that you are mistaken. Nothing is "broken," except for the cryptography in some OTHER coins.

Relax, all is OK in MoneroLand.

[wpalczynski]

IS MONERO BROKEN?

I just looked on chainradar.com and it can tell from which transaction the input is, no matter of the mixin count?

When did this happen? Can't seem to find any thread on this.

Ummm, no.

I am quite sure that you are mistaken. Nothing is "broken," except for the cryptography in some OTHER coins.

Relax, all is OK in MoneroLand.

example:
http://chainradar.com/xmr/transaction/e1969bcf83c0734507c1849a6acc98693deb493890b75d9707fe6b88719e2cce

You have no understanding of how Monero and ring signatures work or you are Trolling.  Since you posted the question with a totally fresh account, no post history at all, I will assume the latter and not take the bait by trying to explain it to you.

[dewdeded]

Regarding a possible Bytecoin release:

I would assume everything from them is some sort of deception or fraud until and unless proven otherwise.

Ullo just wrote:

The next Bytecoin release (1.0.3) is coming out early next week.

[arnuschky]

arnuschky: You are doing very good work, thank you.

Thanks. 

[fluffypony]

I can take a few moneros and do a chain of mixins from one wallet to another to illustrate.
if you do like this:  exchange->wallet A->B->C->D->exchange
then exchange knows tx to wallet A, and tx from wallet D, and on chainradar you will be able to trace tx-es from D to A, so there goes your anonymity.
Yes, it does not show to which address it went, but it links the transactions so you can trace the money.
I think that for it to work, it is supposed to look like on minergate, but now on chainradar you can actually link the tx-es.

Once again, I'm not trolling, I can even demonstrate it with a chain of transactions.

No they don't, they know a transaction occurred but not to where, are you seeing wallet address there or the amount of coins in that wallet? and if you know your transaction or the exchange knows it they can look it in the blockchain but thats it you cant know to what wallet that it went, only the wallet owner has the keys to unlock the real transaction with the right amount of coins, pls be troll.

You are not listening. I will get back to you with a chain of transactions to illustrate the problem.
If exchange sent to wallet A, then from wallet A you sent to wallet B with 100 mixins, then from wallet B back to exchange, in theory exchange should not be able to tell that the money came from wallet A initially. (well it could say that theres a 1% probability it came from wallet A).
But with what I see on chainradar now, exchange will be able to tell that the exact same coins that they deposited into wallet A came back to them from wallet B, because chainradar now has the ability to link transactions regarding of the mixins.   exchange knows tx to wallet a, tx from wallet b, and chainradar will tell you that the input to tx B came from tx A. And in theory, it shouldnt, like we see on minergate.
Try it yourself, if you don't believe me.  
And the most surprising thing is that I cannot find any discussion on how this was achieved.

It's not "achieved".

Practical example: http://chainradar.com/xmr/transaction/a4e445a22c0a0d9435f07ecf55d855d6f277f6428db5cf68ff3bd7bab1ca7829

According to that, the "from transaction" for that input is http://chainradar.com/xmr/transaction/aa10f1d5e589248170404587ab784655458089414b15e90de541776db5d0470c

Except that transaction aa10f1d5e589248170404587ab784655458089414b15e90de541776db5d0470c isn't mine (if anyone else wants to they can indicate it is theirs).

Per simplewallet -


2015-Apr-04 18:12:00.294361 amount=500.000000000000, real_output=19, real_output_in_tx_index=3, indexes: 29 422 478 604 750 1130 1154 1183 1369 1818 2043 2075 2288 2513 2699 3232 3394 3397 3430 3450 3701
2015-Apr-04 18:12:00.333493 transaction <a4e445a22c0a0d9435f07ecf55d855d6f277f6428db5cf68ff3bd7bab1ca7829> generated ok and sent to daemon, key_images: [<1d247030634c590594ab4e6d5cd9abef2daab8dd8df0d3757d2500aa35b1fee6> ]


If I check output 19 (the real output, index 3430) it comes from transaction f563c3dc5c15d582063ea6b8cd34a580c219e1dfcdf3b7fec852a3bec2c1036a. And if I check my incoming_transfers I find that I actually do own that output (which is now spent) -



So at best ChainRadar is broken, at worst they're purposely trying to act as if they can figure out which of the ring signatures is the real one. The only conclusion we can make is that ChainRadar is either incompetent or malicious, and should be avoided.

[fluffypony]

thanks for the clarification.
any ideas how it's guessing the right one most of the time then?

edit:
Do you have a link to the daemon api, or is there an open source block explorer? I want to analyse the blockchain myself, not sure where to start. Thanks

In my tests (20 transactions) they haven't correctly guessed any of them:)

You can try the MoneroBlocks API (not sure if it'll give you enough info for these queries), or use the blockchainDB branch and query the LMDB data (this is probably harder, but closer to what I'm doing).

[vokain]

https://www.fisheaters.com/twomonks.html

[fluffypony]

https://github.com/suthernfriend/blockchaindb  ??
this seems to be for satoshi.
which one are you using?

I prefer to do it locally, since I'll be making many queries and websites might eventually block me.
I could look through the sources, but if it's already done, why rewrite it. 

chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it

https://github.com/tewinget/bitmonero/tree/blockchain

They could be guessing based on one of the temporal association attacks we identified in MRL-0004, but given that they're 0/20 for me I don't know how "educated" the guess is (although 20 is still a small sample size). MLR-0004 can be found here: https://lab.getmonero.org/pubs/MRL-0004.pdf

[eizh]

chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it

If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same.