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

[dEBRUYNE]

something seems odd on moneroblocks.eu:

Height Size Tx Timestamp Block Hash
857514 172 0 2015-12-06 22:27:18 29a7fab8e70f7427e83369e376c703466d659e9e82970c53207efc26a76ac46f
857513 210 0 2015-12-06 22:30:52 0577cccde88d30305510f02d2de74831b0dad75a63a968809245fe6e79e8595c
857512 1609 2 2015-12-06 22:27:25 7828369138ec760bf96621a1f6f618bd4585602719460dbfae1cbca63e025bfe

in this example it shows block 857514 with a timestamp before block 857513 (and before 857512)

whats wrong?
(timestamp seems off on many blocks there, blockheight is higher but timestamp is earlier)

Timestamps are approximate. They are set by the miner but if the miner's computer clock is off, the timestamp will be off. They're still accepted by the network if within some range.

FWIW: This has occured in Bitcoin as well -> https://bitcointalk.org/index.php?topic=391388.0

[1715313864]

1715313864

[megges]

something seems odd on moneroblocks.eu:

Height Size Tx Timestamp Block Hash
857514 172 0 2015-12-06 22:27:18 29a7fab8e70f7427e83369e376c703466d659e9e82970c53207efc26a76ac46f
857513 210 0 2015-12-06 22:30:52 0577cccde88d30305510f02d2de74831b0dad75a63a968809245fe6e79e8595c
857512 1609 2 2015-12-06 22:27:25 7828369138ec760bf96621a1f6f618bd4585602719460dbfae1cbca63e025bfe

in this example it shows block 857514 with a timestamp before block 857513 (and before 857512)

whats wrong?
(timestamp seems off on many blocks there, blockheight is higher but timestamp is earlier)

Timestamps are approximate. They are set by the miner but if the miner's computer clock is off, the timestamp will be off. They're still accepted by the network if within some range.

thanks

don't know what's used to determine if the timestamp (and so the block is in the required range), but i guess the last x blocks are used to get the "real" time, or is there some other way?
I can't guess anything else then it has to be determined on something (blocks) in the blockchain to get a consensus of the "real time".
If so, isn't this an network attack vector?

What if an bad acting miner gets lucky (or owns big hashing power) and finds for example 10 consecutive blocks (xxx1, xxx2, xxx3, xxx4, ..., xx10), if i get it right he is allowed to set the timestamp for the block by his local time, inside the time window, so if he is a bad player and there is a time window of lets say 30 min between each block couldn't he just change the timestamp to something like:
block xxx1 real time + 25min
block xxx2 real time + 50min
block xxx2 real time + 75min
...
block xx10 real time + 250min

so every other miner who will try to submit a block after block xx10 will then be rejected, because their blocks are not in the allowed time window after the last block was 250min "later" then the real timestamp?!
So in the end only the bad acting miner will be able to mine new blocks?!

Does this makes sense? How does the determination/consensus of the "time window" works?

[smooth]

something seems odd on moneroblocks.eu:

Height Size Tx Timestamp Block Hash
857514 172 0 2015-12-06 22:27:18 29a7fab8e70f7427e83369e376c703466d659e9e82970c53207efc26a76ac46f
857513 210 0 2015-12-06 22:30:52 0577cccde88d30305510f02d2de74831b0dad75a63a968809245fe6e79e8595c
857512 1609 2 2015-12-06 22:27:25 7828369138ec760bf96621a1f6f618bd4585602719460dbfae1cbca63e025bfe

in this example it shows block 857514 with a timestamp before block 857513 (and before 857512)

whats wrong?
(timestamp seems off on many blocks there, blockheight is higher but timestamp is earlier)

Timestamps are approximate. They are set by the miner but if the miner's computer clock is off, the timestamp will be off. They're still accepted by the network if within some range.

thanks

don't know what's used to determine if the timestamp (and so the block is in the required range), but i guess the last x blocks are used to get the "real" time, or is there some other way?
I can't guess anything else then it has to be determined on something (blocks) in the blockchain to get a consensus of the "real time".
If so, isn't this an network attack vector?

What if an bad acting miner gets lucky (or owns big hashing power) and finds for example 10 consecutive blocks (xxx1, xxx2, xxx3, xxx4, ..., xx10), if i get it right he is allowed to set the timestamp for the block by his local time, inside the time window, so if he is a bad player and there is a time window of lets say 30 min between each block couldn't he just change the timestamp to something like:
block xxx1 real time + 25min
block xxx2 real time + 50min
block xxx2 real time + 75min
...
block xx10 real time + 250min

so every other miner who will try to submit a block after block xx10 will then be rejected, because their blocks are not in the allowed time window after the last block was 250min "later" then the real timestamp?!
So in the end only the bad acting miner will be able to mine new blocks?!

Does this makes sense? How does the determination/consensus of the "time window" works?

There is a maximum time "ahead" of 120 minutes. No one else will accept the block if it is more than 120 minutes ahead of what they think the current time is. So the miner in your example could mine those blocks but the later ones would be rejected by everyone else for some time period, during which time others would be able to mine different blocks, likely causing the bad miner's effort to be wasted.

There are some potential vulnerabilities having to do with time (look in google for bitcoin time attack or something). Monero is in some ways less vulnerable than Bitcoin because "network time" was never implemented, so you can't mess with nodes' notion of time with a sybil attack on the p2p network.

[Rias]

Yes, its called sweep_dust (already implemented).

Is there any specification of how this feature works?

[smooth]

Yes, its called sweep_dust (already implemented).

Is there any specification of how this feature works?

I'm pretty sure the same exact question was asked (and answered) several posts back. I don't think there is, other than the source code.

I will ask the developer to write up something though, since there does seem to be a fair amount of interest in it.

[MoneroMooo]

Yes, its called sweep_dust (already implemented).

Is there any specification of how this feature works?

The code makes (possibly split) transactions with outputs that are <= dust threshold (or <, can't recall exactly, original CN uses <= to denote dust), and (since recently) also outputs that are not "clean" power of 10. The latter means you could potentially throw in a 10002 monero output. There is no check for the number of potential ring signature fake outputs, so if you have a 100k monero output (lucky you) and no other exists in the blockchain, they sweep_dust (the simplewallet command that does this) will not pick it.

The transaction splitting works the same way as the normal transfer, for cases where there are too many dust outputs to be sent in a single tx. It is possible sweep_dust will fail, due to the 0.01 monero fee per kB. There is no super clever algorithm that'll try to use a large input and lots of smaller ones to lower the likelihood of it, though it'd be possible to add that.

These txes are sent with mixin 0. After the fork, mixin 0 or 1 will only be allowed when at least one input does not have enough fake outs to mix with, and then only one mixable input is allowed with it.

I think that covers it.

[RaginglikeaBoss]

I was playing around with the latest simplewallet today, and wanted to see if I could create a watch-only wallet from my public and view keys using --generate-from-view-key. Like others, I was hoping that this would be a way to check balances on cold wallets without revealing the seed or private keys.

I was surprised to see that the balance after refresh in the watch only wallet did not match the balance in the hot wallet, and it appears that the watch-only wallet only accounts for monero received and not any that were sent. Is this a known issue, or am I doing something wrong here?

I think I know the answer, but to be safe I'm curious to hear a response to your question as well.

[luigi1111]

I was playing around with the latest simplewallet today, and wanted to see if I could create a watch-only wallet from my public and view keys using --generate-from-view-key. Like others, I was hoping that this would be a way to check balances on cold wallets without revealing the seed or private keys.

I was surprised to see that the balance after refresh in the watch only wallet did not match the balance in the hot wallet, and it appears that the watch-only wallet only accounts for monero received and not any that were sent. Is this a known issue, or am I doing something wrong here?

Yes. It's how the protocol works, at least presently.

It's possible to set it up so that you can monitor yourself if you will, but won't work for on-going 3rd party auditing, which I'm completely ok with.

So yes, the title "watch only" is a bit of a misnomer.

[MoneroMooo]

To expand, it is theoretically possible to, when sending a tx, create the tx in such a way that the tx key is derivable by the owner of the view secret key. That way, the watch only wallet would see both incoming txes, and those outgoing txes. If your goal is to view your normal wallet usage, then it'd work fine. I had a patch to do that, which worked IIRC. However, this requires that the spender is not an adversary, as the spender is free to build a tx that does not follow this scheme, in which case the watch wallet user will not see the spend. So in that sense, it is voluntary, and works if the user of both wallets is you, which is a common use case.

If you hold a spend key, and want to give the view key to an adversary, such that the adversary can be sure you can't spend without it being able to tell, there are roundabout ways. A prominent one which was dissussed involves making an unspendable tx (or several) with all your allegedly unspent coins, and give it to the adversary, which can then check the blockchain for the key images. Unspendable in this case means that the tx must be valid, but unredeemable. The easiest way is to double spend an extra output I guess.

That method has the advantage that such snooping is only done at the particular time the spender sends that checking tx. This means that, should a company change auditors, the auditor will not be able to see spends in the future, since no "checking tx" will be sent to them later. Though they will still see incoming txes as they have the view key.

Maybe sending a signed bunch of key images would also just work, not sure.

[MonsterZeroPrice]

Some thoughts about recent price movements.

Well, in the last days we saw a triple top, unfortunately, the third top did not led to a breakout. This scared me and other investors. Thus they decided to wait and place buy orders around 100,000 sat or maybe even lower.

In my opinion it is clear, that there is interest in the coin, but a big issue is the mainstream adoption or not necessarily mainstream but the normal "crypto investor" has not yet been convinced. I do not know how many people are working effectively on this project, but there should be done faster progress. If not, other coins could catch up with monero and this would not be the best case.

No doubt, in case of anonymity, xmr is pretty far ahead of any other altcoin. It would be nice if for example someone could convince a major betting site, currently not accepting any altcoin or btc - let us say bwin to accept monero, moon would not be the limit.

Another thing I noticed concerning altcoins or btc in general is the following. Yesterday I thought I need to buy the new 5k IMAC. Wow, now I can use my btc to buy it. But it turned out that it is not possible to do so if you are loacted in Germany like I am. Especially if you only would send your bitcoin to a trusted site like for example saturn. I really did not chose crypto to buy stuff in btc only by linking my bank account via Kraken or coinbase or others. There must be done something where you have a store which you can trust and buy with altcoins. I would even go to the store and take the IMAC and would like to pay with btc.

[ancientcoins]

xmr is going down, been selling my coins to buy vanilla coin

[luigi1111]

To expand, it is theoretically possible to, when sending a tx, create the tx in such a way that the tx key is derivable by the owner of the view secret key. That way, the watch only wallet would see both incoming txes, and those outgoing txes. If your goal is to view your normal wallet usage, then it'd work fine. I had a patch to do that, which worked IIRC. However, this requires that the spender is not an adversary, as the spender is free to build a tx that does not follow this scheme, in which case the watch wallet user will not see the spend. So in that sense, it is voluntary, and works if the user of both wallets is you, which is a common use case.

If you hold a spend key, and want to give the view key to an adversary, such that the adversary can be sure you can't spend without it being able to tell, there are roundabout ways. A prominent one which was dissussed involves making an unspendable tx (or several) with all your allegedly unspent coins, and give it to the adversary, which can then check the blockchain for the key images. Unspendable in this case means that the tx must be valid, but unredeemable. The easiest way is to double spend an extra output I guess.

That method has the advantage that such snooping is only done at the particular time the spender sends that checking tx. This means that, should a company change auditors, the auditor will not be able to see spends in the future, since no "checking tx" will be sent to them later. Though they will still see incoming txes as they have the view key.

Maybe sending a signed bunch of key images would also just work, not sure.

Bolded above: this should be the proper way to do it. 0-mixin ring sign a hash of the viewkey (or anything else) for all of your inputs.

For creating a "monitor friendly" wallet, we should probably put a bit more thought into it, but mooo's general idea should work.

[luigi1111]

xmr is going down, been selling my coins to buy vanilla coin

Hip.

BTW, there's a speculation thread https://bitcointalk.org/index.php?topic=753252.new#new where you can do all your speculating.

[dEBRUYNE]

In case anyone missed it, a few updates from Shen Noether regarding Confidential Transactions (CT) for Monero:

Edit 11/21/2015: things are slowly coming together - MLSAG's have been coded in python (https://github.com/ShenNoether/MiniNero/blob/master/MLSAG.py) and then I need to get the RingCT code using these rather than the LWW sigs. After this I should be able to finish the size analysis in the paper and then hopefully get a really cleaned up copy available.

edit 11/27/2015: demo version of RingCT using the MLSAG's is coded - next up is implementing 1. Diffie helman passing of masks and 2. implement a short representation of amounts

Most recent version:

https://www.overleaf.com/read/qzgytbyyxvyf

Some more updates:

edit 11/27/2015: demo version of RingCT using the MLSAG's is coded - next up is implementing 1. Diffie helman passing of masks and 2. implement a short representation of amounts

&

edit 12/4/2015: demo version with ECDH passing and short reps is implemented and written up - next is to get this paper looking nicer

Implementation: https://github.com/ShenNoether/MiniNero/commit/4c11983fffb8764837af6727052dc1f34b52c9e4
Write up: https://www.overleaf.com/read/qzgytbyyxvyf

[medusa13]

i did not know this about the viewkey.

doesnt this take all the magic away? i mean maybe i misunderstood, but if you cant see outgoing transactions with the viewkey, how is it usefull at all?
the information that something was there once is not enough for auditing.

an example: monerodice funds get a public audit and a viewkey is posted so everyone can see the bankroll is still there. but...if we cant see outgoing transactions, how do we know?

this picture: https://i.imgur.com/gQlj9Oy.png

is the first point really true? it does not sound possible..it sounds like there has to be some cooperation(using another way to create trx) by the spender so all the transactions are visible, is this correct?


please explain to me, i was absent some time.

[smooth]

i did not know this about the viewkey.

doesnt this take all the magic away? i mean maybe i misunderstood, but if you cant see outgoing transactions with the viewkey, how is it usefull at all?
the information that something was there once is not enough for auditing.

It isn't sufficient for proof-of-solvency. To do that you need a more interactive protocol where the site moves the coins or discloses key images.

It is sufficient for general auditing because you can demand that the owner account for everything that was received. The owner can prove what was spent and can then disclose that proof (either publically or privately to an auditor).

[dEBRUYNE]

i did not know this about the viewkey.

doesnt this take all the magic away? i mean maybe i misunderstood, but if you cant see outgoing transactions with the viewkey, how is it usefull at all?
the information that something was there once is not enough for auditing.

an example: monerodice funds get a public audit and a viewkey is posted so everyone can see the bankroll is still there. but...if we cant see outgoing transactions, how do we know?

this picture: https://i.imgur.com/gQlj9Oy.png

is the first point really true? it does not sound possible..it sounds like there has to be some cooperation(using another way to create trx) by the spender so all the transactions are visible, is this correct?


please explain to me, i was absent some time.

Moneromooo and luigi1111 just discussed a few possible methods to accomplish this (on the top of this same page). MoneroMooo even said he had a patch for on of them. I think it's currently more a matter of figuring out which option is the best (also taking privacy into account).

Also, what smooth said.

[smooth]

To expand, it is theoretically possible to, when sending a tx, create the tx in such a way that the tx key is derivable by the owner of the view secret key. That way, the watch only wallet would see both incoming txes, and those outgoing txes. If your goal is to view your normal wallet usage, then it'd work fine. I had a patch to do that, which worked IIRC. However, this requires that the spender is not an adversary, as the spender is free to build a tx that does not follow this scheme, in which case the watch wallet user will not see the spend. So in that sense, it is voluntary, and works if the user of both wallets is you, which is a common use case.

If you hold a spend key, and want to give the view key to an adversary, such that the adversary can be sure you can't spend without it being able to tell, there are roundabout ways. A prominent one which was dissussed involves making an unspendable tx (or several) with all your allegedly unspent coins, and give it to the adversary, which can then check the blockchain for the key images. Unspendable in this case means that the tx must be valid, but unredeemable. The easiest way is to double spend an extra output I guess.

That method has the advantage that such snooping is only done at the particular time the spender sends that checking tx. This means that, should a company change auditors, the auditor will not be able to see spends in the future, since no "checking tx" will be sent to them later. Though they will still see incoming txes as they have the view key.

Maybe sending a signed bunch of key images would also just work, not sure.

Bolded above: this should be the proper way to do it. 0-mixin ring sign a hash of the viewkey (or anything else) for all of your inputs.

For creating a "monitor friendly" wallet, we should probably put a bit more thought into it, but mooo's general idea should work.

More work needs to go into the bolded portion as well. It has the same negative effects as any other 0-mixin transaction if widely used and disclosed these key image lists are disclosed. The original purpose for which this was proposed at the end of MRL-0004 was for an auditor to verify privately and then destroy. Even that is somewhat dangerous if the same auditor is auditing many clients.

[luigi1111]

To expand, it is theoretically possible to, when sending a tx, create the tx in such a way that the tx key is derivable by the owner of the view secret key. That way, the watch only wallet would see both incoming txes, and those outgoing txes. If your goal is to view your normal wallet usage, then it'd work fine. I had a patch to do that, which worked IIRC. However, this requires that the spender is not an adversary, as the spender is free to build a tx that does not follow this scheme, in which case the watch wallet user will not see the spend. So in that sense, it is voluntary, and works if the user of both wallets is you, which is a common use case.

If you hold a spend key, and want to give the view key to an adversary, such that the adversary can be sure you can't spend without it being able to tell, there are roundabout ways. A prominent one which was dissussed involves making an unspendable tx (or several) with all your allegedly unspent coins, and give it to the adversary, which can then check the blockchain for the key images. Unspendable in this case means that the tx must be valid, but unredeemable. The easiest way is to double spend an extra output I guess.

That method has the advantage that such snooping is only done at the particular time the spender sends that checking tx. This means that, should a company change auditors, the auditor will not be able to see spends in the future, since no "checking tx" will be sent to them later. Though they will still see incoming txes as they have the view key.

Maybe sending a signed bunch of key images would also just work, not sure.

Bolded above: this should be the proper way to do it. 0-mixin ring sign a hash of the viewkey (or anything else) for all of your inputs.

For creating a "monitor friendly" wallet, we should probably put a bit more thought into it, but mooo's general idea should work.

More work needs to go into the bolded portion as well. It has the same negative effects as any other 0-mixin transaction if widely used and disclosed these key image lists are disclosed. The original purpose for which this was proposed at the end of MRL-0004 was for an auditor to verify privately and then destroy. Even that is somewhat dangerous if the same auditor is auditing many clients.

Absolutely. If large lists of key image<>output mappings are made public, that's a potentially big reduction in the anonymity set.

i did not know this about the viewkey.

doesnt this take all the magic away? i mean maybe i misunderstood, but if you cant see outgoing transactions with the viewkey, how is it usefull at all?
the information that something was there once is not enough for auditing.

It isn't sufficient for proof-of-solvency. To do that you need a more interactive protocol where the site moves the coins or discloses key images.

It is sufficient for general auditing because you can demand that the owner account for everything that was received. The owner can prove what was spent and can then disclose that proof (either publically or privately to an auditor).

Just for reference, this has been discussed somewhat in depth quite some time ago, so it's not a new discovery. It might not be widely known outside this thread though.

[smooth]

Just for reference, this has been discussed somewhat in depth quite some time ago, so it's not a new discovery. It might not be widely known outside this thread though.

Yup. Agree on this and your entire comment. Not everyone reads the thread all the time, and new people arrive so it is reasonable to summarize and/or address the same common questions more than once. We are still getting questions about the emission curve (though that was speculation thread). Nothing wrong with that, it is a good sign.