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

Yes that is absolutely true and an advantage over btc mixers would be that the mixer logs would be useless since the mixer itself wouldn't know where the coins came from. With a coinjoin-style mixer the mixer wouldn't even need to know where the coins are going either. With the former you still have the usual issue of the mixer stealing your coins and with the latter you have a simultaneity requirement and timing attacks (as with regular coinjoin). The denominations naturally used in Monero would help with some of the other coinjoin weaknesses (relationships between inputs and output values).

This would provide protection against the threat that someday the "crypto is cracked" and anonymity broken. But then again in the normal course of transactions through merchants, p2p transactions, loans, gambling, etc. there is a lot of natural mixing too.

You can easily add off-chain mixing to a coin that provides on-chain mixing but you can't easily do the opposite.

EDIT: I guess you could pre-derive a one-time destination address even with a receive-and-send mixer, which would remove the recipient address from the mixer's logs too. Currently there is no tooling to send to a precomputed one-time address but I don't see a reason why it couldn't work. Also, I guess there are some issues with r being per-tx not per-output, although I suppose that could be changed to enable this, at the cost of some added space.

Well thats all i really hoped to accomplish was to see if i could get the devs thinking about the general principal in a more abstract sense. if you already are than awesome.

*edit* also, 0.003 

What if monero was funded through fundraising website/programs? I know those websites usually dont allow you to give something in return to those who donate, but they could be directed to a monero exchange where they could buy some if theyd like.

Two problems here. One is the the destination address is one time and the sender can change it with a different choice of r. The other is that you could just wait for another block.

Something like this might be possible based on the key image. That's something I've thought about a bit for another purpose.

right you are sir. thanks for a good post.

*edit* i was thinking the other day, if monero's anonymity is not sufficient for your needs you can always run monero through a tumbler like bitcoin fog. its crazy to think about the difficulty of tracking monero that's been through a tumbler.

Doesn't work as a malicious entity spamming the blockchain during few blocks would own all unspents to be used after that for a while. (and then cascading from then on...).

Anyway I disagree he's right with the issue. You can spend the "blacklisted" inputs into others that are not. In the extreme case you end up with what is described in one of the reddit answer:
+1

What he describes is basically MRL-0001 and what MRL-0004 fixes

So I just had an idea. I literally just thought of it like 1 second ago so i haven't really thought it through. So i was thinking about this post.


And hes right of course. But what if there was a way to prevent transaction authors from being able to chose which mixin partners they used. So for an extremely rough example of the idea. Certainly not saying we should do this, just to demonstrate the principal in a very abstract form. What if for a given transaction to be considered valid you had to hash the destination address + the block header of the previous block and then select the mixin partners that are numerically closest to that hash in terms of absolute value. That way transaction authors would have no choice in who their partners were. This would completely solve the fungibility concerns.

Again im not saying, HEY LETS GO DO THIS, i just want to get the gears turning in peoples heads. maybe be inspiration for some idea that is similar in some way but better.

Not to disagree at all with what fluffypony said but the bigger picture here is that there are almost always core devs and major contributors on #monero-dev and lots of people drop in to get answers to questions about projects they are working on. No one should be reluctant to work on a Monero-related project because they need help. Help is there for you. It is incredibly exciting to see how vibrant and dynamic the third party development surrounding Monero has become.

That to me is more of a positive indicator than the core stuff (which nevertheless continues to move along steadily). The core team can't do it all ourselves, especially without a big war chest from an ICO or premine, but the more we facilitate a vibrant community of Monaro-related development, the more useful Monero will become.

What's a PPM?

Alex Pasternack is the Motherboard editor I believe. alexp at motherboard dot tv

It seems that XMR follows right behind the DRK pump today (Poloniex). I presume we're heading for upper levels (for this 0.003 must become support). Let's see...

He's in #monero-dev often, and we answer his questions as he asks.

More specifically, he has a direct line to me (I even designed the Monero X logo for him), so access to us is REALLY a non-issue.

Connecting to a remote daemon is a bit icky at the moment, it doesn't handle scale beyond a handful of simultaneous requests, and the daemon's RPC API is going away in favour of 0MQ (which will still allow a remote TCP bind, but ill-suited for general-purposes connections). We will look at providing an RPC layer of abstraction for remote clients, but it will be in a separate binary that won't affect the daemon if it dies. I've actively discouraged Jojatekok from relying on remote daemon functionality, as that API isn't frozen and *will* be going away soon.

LOL, i was actually in Vice NYC with one of their PPM's chatting Monero up. She said she'll talk to the motherboard guy about it. This was months ago, maybe it's time to ask again

Yes guaranteed by a startup company that objectively speaking isn't all that credit worthy.

But as I said for small transactions and probably for tax purposes that can be ignored.

That might have been me on the speculation thread. USDT has a fixed value, it's backed by actual USD. It doesn't work like Nxt or BitUSD.



Exactly, I care about making my taxes and math easier, not about a few extra clicks on a couple of websites.

I mean it in the sense of buying it directly with a USD equivalent, which makes calculations much easier in a number of ways, including for tax purposes, and, without going through bitcoins.


They use the OMNI layer (Mastercoin), which is built on the Bitcoin blockchain, and back all TetherUSD with real USD. There's an actual dollar guaranteed there for every TetherUSD that you hold.

You can't use it to buy XMR directly. You have to buy USDT first, which means going through another intermediary and then still using an exchange. USDT is not USD, you can't transfer money from your bank account to Poloniex and get USDT. it is a USD-pegged crypto "token" (I think Nxt-based[, but I'm not positive) Correction: mastercoin-based.

EDIT: On the speculation thread someone pointed out this simplifies tax calculations if you treat USDT as having a fixed value (it really doesn't have a fixed value, but that's a subtlty and maybe the taxman doesn't care). So that is one non-useless thing about it. But as far as number of steps to get from USD to XMR it is the same as going through BTC.

Of course not, but it could be rails to implement what you are suggesting, without involving Bitcoin, simplifying the books of your simplified exchange idea. But we need the volume from people here to close that XMR-TetherUSD buy/ask spread on Poloniex, or it won't even get that far.

List updated on the OP. Sorted first by mixin, second by percentage of donation.
updated by David Latapie

Yes, Circle for XMR would be great.  I'd install the shit out of that app.