Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 734. (Read 4670673 times)

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).

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.

Some more updates:


&


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

Hip.

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

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.

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

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.

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.

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.

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

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.

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.

Is there any specification of how this feature 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.

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?

FWIW: This has occured in Bitcoin as well -> https://bitcointalksearch.org/topic/block-chains-time-stamp-is-nonsequential-391388

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.

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)

I think I might have found one possible reason. Do you have a log for that time (~/.bitmonerod/bitmonerod.log) ? I'm after the lines between 19:34:56.476377 and 19:43:13.872076 on the 1st in that log, to see if it matches what I found.

Edit: nevermind, it can't have been that from your output.

Thanks for the explanation. The power of 10 solution should work well:)