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

[MoneroMooo]

There is a list of wallet RPC calls here: https://github.com/moneromooo-monero/monero-site/commits/wallet-rpc

None for the daemon though.

[1713516559]

1713516559

[1713516559]

1713516559

[1713516559]

1713516559

[elrippo]

Hy guys 

I think i am facing a small problem with 0.8.8.6 on Kubuntu 14.04LTS 64bit

I have a locked balance of n and an unlocked balance of n-100
The 100XMR difference comes from a buy at poloniex.com two weeks ago.
Is there a possibility to get the locked 100XMR manually into unlocked state?

Thanks in advance,
elrippo

I would try backing up all the wallet files first, then delete the .dat file and reopen the wallet. It should recreate the wallet from the .keys file, rescan the blockchain, and hopefully recover the coins in an unlocked state. If that doesn't work, then something else went wrong. Let us know.

Hy Smooth,
thanks for your reply, but i am not able to find the *.dat file.

Sorry, my mistake. The file is normally called wallet.bin not wallet.dat.

EDIT: Looks like you worked out your issue. Glad to hear that.

Hy Smooth,
no problem, we are all just people
Jope, deleting the wallet.bin file and reindexing worked out the issue 

[elrippo]

Code:

ls -la .bitmonero
drwxrwxr-x  2    4096 Jul 26 07:38 .
drwx------ 51    16384 Jul 26  2015 ..
-rwxr-xr-x  1    5599313 Dez 10  2014 bitmonerod
-rw-rw-r--  1    694898 Jul 26 07:38 bitmonerod.log
-rw-rw-r--  1    4622968840 Jul 26 07:38 blockchain.bin
-rw-rw-r--  1    5947165 Feb  6 15:52 blockchain.bin.part
-rw-rw-r--  1    3308201 Feb  6 14:44 monero.linux.x64.v0-8-8-6b.tar.bz2
-rw-rw-r--  1    164405 Jul 26 07:38 p2pstate.bin
-rw-rw-r--  1    10056 Jul 26 07:36 poolstate.bin
-rwxr-xr-x  1    4762673 Dez 10  2014 simplewallet
-rw-rw-r--  1    84553687 Jul 26 07:36 simplewallet.log
-rw-rw-r--  1    27034896 Jul 26 07:36 wallet.bin
-rw-rw-r--  1    95 Feb  6 14:48 wallet.bin.address.txt
-rw-rw-r--  1    509 Feb  6 14:48 wallet.bin.keys

Could you please readvise what i can do. I hope i must not reload the blockchain....

The blockchain is here (blockchain.bin). You can get rid of blockchain.bin.part if yo don't otherwise need it.
The keys file which you need to keep is wallet.bin.keys. The cache file which you can nuke is wallet.bin.
Do that while simplewallet is not running. The daemon can be running.

Thanks, that did the trick 

hodlers hate this guy

Why so and whom shall they hate 

[arnuschky]

Is there any RPC documentation for that is up to date? Before we always used the Bytecoin wiki, but it's rather outdated now - the devs added some RPC calls lately, right?

There have not been major changes recently, only a few minor ones. There has been work on revamping the RPCs but that is not in master yet.

There is not completely RPC documentation that is up to date, unfortunately. The best place to look is the code, which in that respect is quite readable.

https://github.com/monero-project/bitmonero/blob/master/src/wallet/wallet_rpc_server_commands_defs.h
https://github.com/monero-project/bitmonero/blob/master/src/rpc/core_rpc_server_commands_defs.h

Thanks, also at MoneroMooo. Where can I take a peek at the new RPC interface? Or is it not even on github yet?

[smooth]

Is there any RPC documentation for that is up to date? Before we always used the Bytecoin wiki, but it's rather outdated now - the devs added some RPC calls lately, right?

There have not been major changes recently, only a few minor ones. There has been work on revamping the RPCs but that is not in master yet.

There is not completely RPC documentation that is up to date, unfortunately. The best place to look is the code, which in that respect is quite readable.

https://github.com/monero-project/bitmonero/blob/master/src/wallet/wallet_rpc_server_commands_defs.h
https://github.com/monero-project/bitmonero/blob/master/src/rpc/core_rpc_server_commands_defs.h

Thanks, also at MoneroMooo. Where can I take a peek at the new RPC interface? Or is it not even on github yet?

I think here but not sure if it is entirely up to date: http://monero.wikia.com/wiki/RPC_API

[smooth]

There is a list of wallet RPC calls here: https://github.com/moneromooo-monero/monero-site/commits/wallet-rpc

Nice! I was not aware of that documentation work being done. Looks great!

[XMRpromotions]

Cross post from https://www.reddit.com/r/Monero/comments/3erujn/moneropromotions_is_coming_soon_please_follow_to/:

Please follow us:

https://twitter.com/XMRpromotions

We have a list of exchanges and merchants we would like to see add Monero but remain open to suggestions. First task will be to focus on BTC38. After we gain some followers (including people who already trade there) we will solicit their help in encouraging BTC38 to add Monero. Users that have never used Monero may be given small amounts to test out for free. When new Monero services are launched or when a new merchant accepts Monero, we will help raise awareness. Eventually different groups of followers will help us target different regions, industries and demographics. We believe Monero will become a global phenomenon in the years to come and want to help foster that growth.

[Hueristic]

Is there any RPC documentation for that is up to date? Before we always used the Bytecoin wiki, but it's rather outdated now - the devs added some RPC calls lately, right?

There have not been major changes recently, only a few minor ones. There has been work on revamping the RPCs but that is not in master yet.

There is not completely RPC documentation that is up to date, unfortunately. The best place to look is the code, which in that respect is quite readable.

https://github.com/monero-project/bitmonero/blob/master/src/wallet/wallet_rpc_server_commands_defs.h
https://github.com/monero-project/bitmonero/blob/master/src/rpc/core_rpc_server_commands_defs.h

As a matter of fact where can I get a list of all the code that is now "All quite readable"? I can't believe there isn't even a simple flowchart or block diagram available. I'm starting to think this project has forgotten what open source stands for. I under stand the inherited code was intentionally obfuscated but I am not seeing any efforts to remedy this in a "Open way", Or maybe I just don't have the skills to find this information as I stopped programming before Github existed and everyone thinks if it's there in any form then it is open. If I throw a pail of water into the ocean I can't say it's accessible.

As you can tell I'm getting a bit frustrated at these off the cuff comments "Go look at the code it's there". This is the shit that raised red flags. I understand the desire to keep information in the insiders club mentality, it's used in financial scams all day long but if this project is ever going to be adopted then these issues need addressing.

This is the only graphical representation I've been able to find and I'm not sure if it's correct.

[medusa13]

hey i think you mix two differen things up:

he was asking for RPC documentation. This means he just want to see a place where he can see what parameters he has to give to a function and what he will be getting back. the best solution to do this IS looking inside the code, since even people that can not code could read it if they know what they are looking for.

the thing you are talking about is documentation about cryptonode internal functionallity like ring signatures, stealth addresses etc. i agree documentation on this things are not good enough for the common public, but this was not the right way to bring this issue up since smooths answer was the best one to give.

how to deal with it? the funding page needs more content anyway and people at monero forum are trying to define a work package for the "monero about" page (https://forum.getmonero.org/7/open-tasks/346/about-monero-page-content). this would be the right way to go if your intention to change this should bear fruits one day . maybe we could inculde it there ?

the problem is, there are not a lot people who really know how all this works. only the devs can make such graphs

[luigi1111]

Is there any RPC documentation for that is up to date? Before we always used the Bytecoin wiki, but it's rather outdated now - the devs added some RPC calls lately, right?

There have not been major changes recently, only a few minor ones. There has been work on revamping the RPCs but that is not in master yet.

There is not completely RPC documentation that is up to date, unfortunately. The best place to look is the code, which in that respect is quite readable.

https://github.com/monero-project/bitmonero/blob/master/src/wallet/wallet_rpc_server_commands_defs.h
https://github.com/monero-project/bitmonero/blob/master/src/rpc/core_rpc_server_commands_defs.h

As a matter of fact where can I get a list of all the code that is now "All quite readable"? I can't believe there isn't even a simple flowchart or block diagram available. I'm starting to think this project has forgotten what open source stands for. I under stand the inherited code was intentionally obfuscated but I am not seeing any efforts to remedy this in a "Open way", Or maybe I just don't have the skills to find this information as I stopped programming before Github existed and everyone thinks if it's there in any form then it is open. If I throw a pail of water into the ocean I can't say it's accessible.

As you can tell I'm getting a bit frustrated at these off the cuff comments "Go look at the code it's there". This is the shit that raised red flags. I understand the desire to keep information in the insiders club mentality, it's used in financial scams all day long but if this project is ever going to be adopted then these issues need addressing.

This is the only graphical representation I've been able to find and I'm not sure if it's correct.

Yes, that looks correct. It looks hard to parse if you don't already understand what's going on though (to me).

I'm not sure it's actually possible to put it together in an easy-to-understand way for "noobs".

Edit: and has nothing to do with RPC commands at all, as medusa13 points out.

[luigi1111]

hey i think you mix two differen things up:

he was asking for RPC documentation. This means he just want to see a place where he can see what parameters he has to give to a function and what he will be getting back. the best solution to do this IS looking inside the code, since even people that can not code could read it if they know what they are looking for.

the thing you are talking about is documentation about cryptonode internal functionallity like ring signatures, stealth addresses etc. i agree documentation on this things are not good enough for the common public, but this was not the right way to bring this issue up since smooths answer was the best one to give.

how to deal with it? the funding page needs more content anyway and people at monero forum are trying to define a work package for the "monero about" page (https://forum.getmonero.org/7/open-tasks/346/about-monero-page-content). this would be the right way to go if your intention to change this should bear fruits one day . maybe we could inculde it there ?

the problem is, there are not a lot people who really know how all this works. only the devs can make such graphs

I wouldn't say *only* the devs, as I'm not a "dev", but have a pretty decent understanding of how it all works.

[medusa13]

yes i agree i also managed to develop a better understanding, but still there are black holes. but i dont think a graph can fix this anyway.
looking at the above picture and listening to the "understanding monero" podcast helped me a lot! (https://letstalkbitcoin.com/blog/post/ltb-e202-understanding-monero)

i couldnt draw such a graph myself out of my head, maybe one day

maybe this would be content for the wiki or a separate section of the monero page, "monero/cryptonote internals" or whatever

[GingerAle]

just write a narrative of the diagram following the numbers. I've never tried this, here goes

1. from the blockchain, a transactions public key is mashed together with a random number
2. a specific output is used
3. bobs private key is used
4. the above three things are mashed together into a private key
5. another random number mashes with a public key
6. number 5 gets mashed with the following

and I got lost and im at work and peeps gettin coffee.

[luigi1111]

just write a narrative of the diagram following the numbers. I've never tried this, here goes

1. from the blockchain, a transactions public key is mashed together with a random number
2. a specific output is used
3. bobs private key is used
4. the above three things are mashed together into a private key
5. another random number mashes with a public key
6. number 5 gets mashed with the following

and I got lost and im at work and peeps gettin coffee.

Well, no, that's not really how it works.

1. For the sender, a random transaction private key is chosen.
2. The sender does a ECDH with this private key and the receiver's public view key.
3. From that derivation and an output index, he is able to use the receiver's public spend key to create a one-time output public key for which only the receiver will be able to generate a private key.

To generate this private key:

1. The receiver does an ECDH with his private view key and the public transaction key (from tx extra)
2. From this derivation (which matches exactly that from step 2 above), the receiver does the same as step 3 above.
3. If his result matches, he knows he owns the output. He can then use his private spend key to generate the corresponding output private key (to actually spend the output).

Edit: this is just stealth addresses, and has nothing in particular to do with the flowchart; I kinda missed that part of GingerAle's post.

[dnaleor]

just write a narrative of the diagram following the numbers. I've never tried this, here goes

1. from the blockchain, a transactions public key is mashed together with a random number
2. a specific output is used
3. bobs private key is used
4. the above three things are mashed together into a private key
5. another random number mashes with a public key
6. number 5 gets mashed with the following

and I got lost and im at work and peeps gettin coffee.

let me give it a try

Bob wants to spend XMR he received in his account and send it to Carol.
How does he compose the transaction?

A: Bob gets acces to his "real input" that was send to his "stealth address"
1. Bob needs the public key from the transaction that contains the output he received and wants to send
2. Bob also selects the exact number of the output from the transaction that contains the output he wants to send. The other output(s) in this transaction is/are change (Bob doesn't have the private key for those other outputs)
3. Bob needs the "master" private key of his account
4. 1,2 and 3 are used to calculate the private key for the specific output he wants to send. (the public key for the transaction can be calculated from this private key)

B: to protects Carol's identity, Bob will do the folowing to generate a "one time" public key for this transaction, making it impossible for others to link all transactions send to Carol to the same "stealth address"
5. Bob generates a random number
6. this random number is hashed into the transaction public key
7. he selects the number associated with the output that Carol will receive, the other output(s) is/are change that goes back to Bob.
8. he needs the "master" public key from Carol to be able to send it to her stealth address
9. 6,7 and 8 are used to calulate the public key for the specific output he wants to send

C: to "mix" the inputs, Bob creates a ring signature
10.  He selects the actual public key from the output he wants to send, but he also adds other public keys into the mix.
11. to prevent double spending, Bob needs to send a valid "key image" together with the public keys of the outputs.
12. he signs the combination of inputs and the key image with his private key, prooving the key image is valid (Bob owns the private key associated with the key image) and that (somehow? I don't know how this works) one of the public keys is used to generate this key image, but as a spectator of the blockchain, we can't know which of the used outputs is "the real one that is being transferred".
13. This is the collection of outputs that is signed. He grabbed the "fake ones" from the blockchain. He doesn't need permission from the owners for that.
14. This is the key image he signed. If Bob ever tries to send the same output again, the exact same key image will be generated and thus the double spend will be detected.
15. this "ring signature" is added to the transaction containing the publi keys that are used in the transaction and proving Bob's ownership of one of those inputs.



tell me if I was terribly wrong


edit: damn it, luigiiii is faster than me

[generalizethis]

just write a narrative of the diagram following the numbers. I've never tried this, here goes

1. from the blockchain, a transactions public key is mashed together with a random number
2. a specific output is used
3. bobs private key is used
4. the above three things are mashed together into a private key
5. another random number mashes with a public key
6. number 5 gets mashed with the following

and I got lost and im at work and peeps gettin coffee.

let me give it a try

Bob wants to spend XMR he received in his account and send it to Carol.
How does he compase the transaction?

A: Bob gets acces to his "real input" that was send to his "stealth address"
1. Bob needs the public key from the transaction that contains the output he received and wants to send
2. Bob also selects the exact number of the output from the transaction that contains the output he wants to send. The other output(s) in this transaction is/are change (Bob doesn't have the private key for those other outputs)
3. Bob needs the "master" private key of his account
4. 1,2 and 3 are used to calculate the private key for the specific output he wants to send. (the public key for the transaction can be calculated from this private key)

B: to protects Carol's identity, Bob will do the folowing to generate a "one time" public key for this transaction, making it impossible for others to link all transactions send to Carol to the same "stealth address"
5. Bob generates a random number
6. this random number is hashed into the transaction public key
7. he selects the number associated with the output that Carol will receive, the other output(s) is/are change that goes back to Bob.
8. he needs the "master" public key from Carol to be able to send it to her stealth address
9. 6,7 and 8 are used to calulate the public key for the specific output he wants to send

C: to "mix" the inputs, Bob creates a ring signature
10.  He selects the actual public key from the output he wants to send, but he also adds other public keys into the mix.
11. to prevent double spending, Bob needs to send a valid "key image" together with the public keys of the outputs.
12. he signs the combination of inputs and the key image with his private key, prooving the key image is valid (Bob owns the private key associated with the key image) and that (somehow? I don't know how this works) one of the public keys is used to generate this key image, but as a spectator of the blockchain, we can't know which of the used outputs is "the real one that is being transferred".
13. This is the collection of outputs that is signed. He grabbed the "fake ones" from the blockchain. He doesn't need permission from the owners for that.
14. This is the key image he signed. If Bob ever tries to send the same output again, the exact same key image will be generated and thus the double spend will be detected.
15. this "ring signature" is added to the transaction containing the publi keys that are used in the transaction and proving Bob's ownership of one of those inputs.



tell me if I was terribly wrong


edit: damn it, luigiiii is faster than me

This voiced over an animation of the transaction would be a great guide to how a Monero transaction happens.

[GingerAle]

just write a narrative of the diagram following the numbers. I've never tried this, here goes

1. from the blockchain, a transactions public key is mashed together with a random number
2. a specific output is used
3. bobs private key is used
4. the above three things are mashed together into a private key
5. another random number mashes with a public key
6. number 5 gets mashed with the following

and I got lost and im at work and peeps gettin coffee.

Well, no, that's not really how it works.

1. For the sender, a random transaction private key is chosen.
2. The sender does a ECDH with this private key and the receiver's public view key.
3. From that derivation and an output index, he is able to use the receiver's public spend key to create a one-time output public key for which only the receiver will be able to generate a private key.

To generate this private key:

1. The receiver does an ECDH with his private view key and the public transaction key (from tx extra)
2. From this derivation (which matches exactly that from step 2 above), the receiver does the same as step 3 above.
3. If his result matches, he knows he owns the output. He can then use his private spend key to generate the corresponding output private key (to actually spend the output).

I figured as much, but that was my point - the diagram is not very helpful for those of us that are all like "my compooter gone did done some mafs"

Thank you though! - the above is short and sweet, but dnaelor's actually matched up with the diagram numbers. And yes, one of those "floating hand draws and some guy talks" animation things would be cool

[luigi1111]

just write a narrative of the diagram following the numbers. I've never tried this, here goes

1. from the blockchain, a transactions public key is mashed together with a random number
2. a specific output is used
3. bobs private key is used
4. the above three things are mashed together into a private key
5. another random number mashes with a public key
6. number 5 gets mashed with the following

and I got lost and im at work and peeps gettin coffee.

Well, no, that's not really how it works.

1. For the sender, a random transaction private key is chosen.
2. The sender does a ECDH with this private key and the receiver's public view key.
3. From that derivation and an output index, he is able to use the receiver's public spend key to create a one-time output public key for which only the receiver will be able to generate a private key.

To generate this private key:

1. The receiver does an ECDH with his private view key and the public transaction key (from tx extra)
2. From this derivation (which matches exactly that from step 2 above), the receiver does the same as step 3 above.
3. If his result matches, he knows he owns the output. He can then use his private spend key to generate the corresponding output private key (to actually spend the output).

I figured as much, but that was my point - the diagram is not very helpful for those of us that are all like "my compooter gone did done some mafs"

Thank you though! - the above is short and sweet, but dnaelor's actually matched up with the diagram numbers. And yes, one of those "floating hand draws and some guy talks" animation things would be cool

Yes, I was only covering the stealth address portion, which, IMO, is harder to "get" than the ring signature portion. dnaleor's covers the full transaction, but also isn't quite correct.

The graphic doesn't really explain stealth addresses at all, so the first part of this is basically inline, but I've added a bit to it anyway.

let me give it a try

Bob wants to spend XMR he received in his account and send it to Carol.
How does he compose the transaction?

A: Bob gets acces to his "real input" that was send to his "stealth address"
1. Bob needs the public key from the transaction that contains the output he received and wants to send - Bob needs to ECDH this key with his private view key
2. Bob also selects the exact number of the output from the transaction that contains the output he wants to send. The other output(s) in this transaction is/are change (Bob doesn't have the private key for those other outputs) Note: typically, due to auto-denomination, Bob will have more than one output per transaction that belongs to him.
3. Bob needs the "master" private key of his account - private spend key, to be precise
4. 1,2 and 3 are used to calculate the private key for the specific output he wants to send. (the public key for the transaction can be calculated from this private key - This is correct, but the public key is also stored on the blockchain.)

B: to protects Carol's identity, Bob will do the folowing to generate a "one time" public key for this transaction, making it impossible for others to link all transactions send to Carol to the same "stealth address"
5. Bob generates a random number scalar, this one isn't clear from the graphic at all
6. this random number is hashed into the transaction public key the transaction private key, and is scalar mult'd into the transaction public key
7. he selects the number associated with the outputs (due to auto-denom) that Carol will receive, the other output(s) is/are change that goes back to Bob.
8. he needs the "master" public key from Carol to be able to send it to her stealth address - Carol's public view key
9. 6,7 and 8 are used to calulate the public key for the specific outputs he wants to send

C: to "mix" the inputs, Bob creates a ring signature
10.  He selects the actual public key (+ that output's private key) from the output he wants to send, but he also adds other public keys into the mix.
11. to prevent double spending, Bob needs to send a valid "key image" together with the public keys of the outputs (or inputs if you prefer).
12. he signs the combination of inputs and the key image with his private key, prooving the key image is valid (Bob owns the private key associated with the key image) and that (somehow? I don't know how this works) one of the public keys is used to generate this key image, but as a spectator of the blockchain, we can't know which of the used outputs is "the real one that is being transferred". His private key and the other chosen public key(s) are used to create a ring signature; they'll be one signature for each input, collectively making a ring signature. The key image is an additional public key computed from the output private key (not public key) that's actually being spent.
13. This is the collection of outputs that is signed. He grabbed the "fake ones" from the blockchain. He doesn't need permission from the owners for that. This isn't quite right: those are the outputs that are doing the signing. A hash of the TX prefix is "what" is actually being signed.
14. This is the key image he signed. If Bob ever tries to send the same output again, the exact same key image will be generated and thus the double spend will be detected.
15. this "ring signature" is added to the transaction containing the publi keys that are used in the transaction and proving Bob's ownership of one of those inputs.



tell me if I was terribly wrong


edit: damn it, luigiiii is faster than me

[dnaleor]

My question isn't really answered yet:

how can a spectator know that the image key is associated with at least on of the inputs in the transaction?
If we can't verify that, Bob can just make up an image key, send it along and keep double spending his funds

It's probably obvious, but I don't see it


edit: btw, thx for the annotations, Luiigiiiii
I knew that due to the denominations, there are a lot of in and outputs, but didn't want to make it more complicated than necessary.


edit2: the transaction private key is never used, am I right? It's only used to calculate the transaction public key?

[kenji]

what is the different between monerowallet.com and mymonero.com?