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

[Lloydimiller4]

It's a screenshot from letter by "Moneero" company. They agreed that "monero" is a common word.


And now they write us:
"We have trademark moneey, therefore you can not use money in domain names"

Good, they told you how to refute their claim. 

Exactly, this should be a non-issue. I would simply ignore them, they seem to be butt-hurt over nonsense.

[1715570245]

1715570245

[1715570245]

1715570245

[fluffypony]

Exactly, this should be a non-issue. I would simply ignore them, they seem to be butt-hurt over nonsense.

You mean buutt-huurt, right?

[smooth]

I know you can hop on github and follow the commits... but not everyone in here is able to translate that into something meaningful.

When the devs are busy, maybe some of the technically adept monero supporters could translate it and put it in this thread now and then?

That is a good suggestion. if someone wants to take it on i volunteer to answer questions that might come up about the purpose of or function of various commits and pull requests.

Perhaps it would be a good idea if you made some kind of digest like GingerAle did, but then with the week's commits? If it requires too much of your free time, the funding system would be a proper place to get some funds for it in my opinion. Furthermore, like Gingerale, I guess you'll receive some donations without even asking for it.

To be clear  I was not volunteering to create and publish the list (not something I would be good at with my erratic availability of free time anyway). I was volunteering to help someone do it by answering technical questions about the commits and pull requests when needed. So someone creating the list would not necessarily need to fully understand the code and/or discussions (but some degree of understanding would be helpful).

[kazuki49]

Even if you use Bitcoin through Tor, the way transactions are handled by the network makes anonymity difficult to achieve. Do not expect your transactions to be anonymous unless you really know what you're doing.

Just read this as bitcointalk "ad", just wtf is expected from us to use Bitcoin with a reasonable level of privacy? Total joke. I would still prefer Monero over anything else even if it had to be renamed (won't happen) to darkflabb.

[GingerAle]

Exactly, this should be a non-issue. I would simply ignore them, they seem to be butt-hurt over nonsense.

You mean buutt-huurt, right?

I think wee should takee up using double ee's in all instancees of words. Theen Moneero might havee a casee against our "company", which would theen be called Moneero.

[LuxMoneroj]

Monero.io is registered. Anyone here own it?

[MoneroMooo]

I know you can hop on github and follow the commits... but not everyone in here is able to translate that into something meaningful.

When the devs are busy, maybe some of the technically adept monero supporters could translate it and put it in this thread now and then?

That is a good suggestion. if someone wants to take it on i volunteer to answer questions that might come up about the purpose of or function of various commits and pull requests.

That's something I can try to do. I have some familiarity with the monero code, which should help.

Donated 10 XMR to Moneromooo for http://moneroaddress.org/

This is great work!

Thanks

[Anon136]

So I don't know if you guys have seen the news about this proposal called "offcoin" http://www.coindesk.com/netopia-internet-free-bitcoin-transactions/ but it looks really cool and really exciting. It's rare that I will forgive a project for being closed source, but this one has to be closed source by it's nature, and still can be sufficiently trustworthy even considering.

Anyway one beautiful thing about it is that it will have a really significant positive externality on the privacy of everyone including people who never even use the product. Essentially it will make it so that there is no way for a third party observing the blockchain to know if the person who is in control of an address when it receives funds is the same person who is in control of it when funds are sent from that address. In essence it will give bitcoin an, admittedly imperfect, measure of unlinkability or at least link plausible deniability (though i think it would definitively go beyond plausible deniability).

So the point of all of this is not to say "sell all moneros bitcoin going to be anonymous soon". Clearly this is at best a partial solution. But if monero were to leverage up this technology it would make our privacy features only that much more robust. We could pay the same as we are paying now for privacy and get even more of it, or we could pay less for the same amount.

Since the code is closed source it will have to be entirely rewritten, so that's a bummer. But one nice thing is that none of the things that make monero different from bitcoin make implementing this idea within monero one iota more difficult than implementing it with bitcoin.

Some stuff worth thinking and talking about I think.

[binaryFate]

So I don't know if you guys have seen the news about this proposal called "offcoin" http://www.coindesk.com/netopia-internet-free-bitcoin-transactions/ but it looks really cool and really exciting. It's rare that I will forgive a project for being closed source, but this one has to be closed source by it's nature, and still can be sufficiently trustworthy even considering.

Anyway one beautiful thing about it is that it will have a really significant positive externality on the privacy of everyone including people who never even use the product. Essentially it will make it so that there is no way for a third party observing the blockchain to know if the person who is in control of an address when it receives funds is the same person who is in control of it when funds are sent from that address. In essence it will give bitcoin an, admittedly imperfect, measure of unlinkability or at least link plausible deniability (though i think it would definitively go beyond plausible deniability).

So the point of all of this is not to say "sell all moneros bitcoin going to be anonymous soon". Clearly this is at best a partial solution. But if monero were to leverage up this technology it would make our privacy features only that much more robust. We could pay the same as we are paying now for privacy and get even more of it, or we could pay less for the same amount.

Since the code is closed source it will have to be entirely rewritten, so that's a bummer. But one nice thing is that none of the things that make monero different from bitcoin make implementing this idea within monero one iota more difficult than implementing it with bitcoin.

Some stuff worth thinking and talking about I think.

I don't find it that exciting. Anyway because of the part I bolded, it's doomed to fail. It relies on being closed source to work? It's like having security by obscurity only. It will work until it won't work because a kid disassemble it and tweak something to get a version that doesn't erase the private keys after handing them to another person. This will happen *very* fast.

[kazuki49]

So I don't know if you guys have seen the news about this proposal called "offcoin" http://www.coindesk.com/netopia-internet-free-bitcoin-transactions/ but it looks really cool and really exciting. It's rare that I will forgive a project for being closed source, but this one has to be closed source by it's nature, and still can be sufficiently trustworthy even considering.

Anyway one beautiful thing about it is that it will have a really significant positive externality on the privacy of everyone including people who never even use the product. Essentially it will make it so that there is no way for a third party observing the blockchain to know if the person who is in control of an address when it receives funds is the same person who is in control of it when funds are sent from that address. In essence it will give bitcoin an, admittedly imperfect, measure of unlinkability or at least link plausible deniability (though i think it would definitively go beyond plausible deniability).

So the point of all of this is not to say "sell all moneros bitcoin going to be anonymous soon". Clearly this is at best a partial solution. But if monero were to leverage up this technology it would make our privacy features only that much more robust. We could pay the same as we are paying now for privacy and get even more of it, or we could pay less for the same amount.

Since the code is closed source it will have to be entirely rewritten, so that's a bummer. But one nice thing is that none of the things that make monero different from bitcoin make implementing this idea within monero one iota more difficult than implementing it with bitcoin.

Some stuff worth thinking and talking about I think.

I don't find it that exciting. Anyway because of the part I bolded, it's doomed to fail. It relies on being closed source to work? It's like having security by obscurity only. It will work until it won't work because a kid disassemble it and tweak something to get a version that doesn't erase the private keys after handing them to another person. This will happen *very* fast.

Yeah its not, its almost as stupid as moneero from urgay, a coin need to be neat and simple, thats why complex blockchain systems like ethereum, ripple and nxt will never take off.

[5w00p]

So I don't know if you guys have seen the news about this proposal called "offcoin" http://www.coindesk.com/netopia-internet-free-bitcoin-transactions/ but it looks really cool and really exciting. It's rare that I will forgive a project for being closed source, but this one has to be closed source by it's nature, and still can be sufficiently trustworthy even considering.

Anyway one beautiful thing about it is that it will have a really significant positive externality on the privacy of everyone including people who never even use the product. Essentially it will make it so that there is no way for a third party observing the blockchain to know if the person who is in control of an address when it receives funds is the same person who is in control of it when funds are sent from that address. In essence it will give bitcoin an, admittedly imperfect, measure of unlinkability or at least link plausible deniability (though i think it would definitively go beyond plausible deniability).

So the point of all of this is not to say "sell all moneros bitcoin going to be anonymous soon". Clearly this is at best a partial solution. But if monero were to leverage up this technology it would make our privacy features only that much more robust. We could pay the same as we are paying now for privacy and get even more of it, or we could pay less for the same amount.

Since the code is closed source it will have to be entirely rewritten, so that's a bummer. But one nice thing is that none of the things that make monero different from bitcoin make implementing this idea within monero one iota more difficult than implementing it with bitcoin.

Some stuff worth thinking and talking about I think.

I don't find it that exciting. Anyway because of the part I bolded, it's doomed to fail. It relies on being closed source to work? It's like having security by obscurity only. It will work until it won't work because a kid disassemble it and tweak something to get a version that doesn't erase the private keys after handing them to another person. This will happen *very* fast.

That's basically what I was thinking, as the proprietary SD card is eventually (or quickly) likely to be reverse-engineered.

But, it should be an interesting experiment to observe.

[cAPSLOCK]

Exactly, this should be a non-issue. I would simply ignore them, they seem to be butt-hurt over nonsense.

You mean buutt-huurt, right?

You knoow he is not alloowed to mean that!

[Lloydimiller4]

Exactly, this should be a non-issue. I would simply ignore them, they seem to be butt-hurt over nonsense.

You mean buutt-huurt, right?

You knoow he is not alloowed to mean that!

I guess I need to go back to grade school and learn to speel propeerly.

[jwinterm]

...
Yeah its not, its almost as stupid as moneero from urgay, a coin need to be neat and simple, thats why complex blockchain systems like ethereum, ripple and nxt will never take off.

You forgot about MAIDsafe, the most complicated system ever devised that will do everything from route internet traffic to switch traffic lights in the utopic land of cryptopia. Apparently they posted some significant progress update today.

[Anon136]

I don't find it that exciting. Anyway because of the part I bolded, it's doomed to fail. It relies on being closed source to work? It's like having security by obscurity only. It will work until it won't work because a kid disassemble it and tweak something to get a version that doesn't erase the private keys after handing them to another person. This will happen *very* fast.

Yes of course. Its not as if I haven't thought through all of this myself already. But there are reasons why I said what i said after the bolded part.

The most important thing to understand is that "can it be hacked?" is the wrong question. The important question is how costly will hacking it be and how great will the benefits be. (or for the more economically minded among you, technically the question is closer to, when the market reacts to hackers by lowering the amount of money people are willing to accept on one of these chips to the point where the marginal hacker finds it no longer worth his time, will that amount be too low for this technology to be sufficiently useful).

You are not going to be using this thing to buy a car or a house. Transactions like that will be done on the blockchain. You will be using it to buy a soda or a tank of gas or a game from the steam store. Sure there is a risk that some kid will dig into it with a microscope. Of course. But we have a perfect analog for this already with blockchains exactly the way they work now. People will accept 0 confirmation transactions on small purchases even though they could be reversed by a dedicated attacker. So what? Is the solution to force someone who is buying a soda to wait for 3 confirmations? As a market actor you just weigh the risks against the benefits and you decide for yourself what is your preferred trade off. If you are risk averse you have a lower threshold for amounts that you are willing to accept off chain, for the sorts of people you are willing to accept certain types of transactions from, and how often you settle up on the blockchain.

Understand what we are talking about here. Understand the promise. Understand what is at stake. What we are talking about here is a measure of unlinkability for all crypto users, instantaneous transactions, offline transactions, free transactions, the massive reduction of blockchain bloat, and the solution to the scalability problem. These things collectively, in their totality, ARE HUGE! When you dismiss it out of hand its tantamount to saying this medicine that will save my life tastes bad and gives me a tummy ache, so forget it.

This "solution" to doublespending could never be a replacement to satoshi's solution. It could never act as an alternative to blockchains. But it definitely can act as an amazing complement by leverage up satoshi's amazing invention to help make up for some of the shortcomings of this type of doublespend "solution". Togather, and only togather, they could make something beautiful.

Of course all of this this depends on how difficult it is to hack. If its too easy or too expensive to stay ahead of the curve in the arms race than it will be a footnote in history. If not it could take crypto to who new places. Only time will tell that but the chance that it will work is exciting as hell.

*edit* and i should add. this is the first time in my life that i have ever been excited about a closed source project. (excluding things like video games). So I definitely feel your concern. Its not as if im some closed source fan boy.

[TPTB_need_war]

Because I am not up-to-speed on communicating with the Monero devs (on Github or other back channels), and because my efficiency is my utmost priority and given posting in this forum is the most efficient way for me to communicate my thoughts to all that follow me, I will post this somewhat out-of-band comment here in hopes of getting a response from smooth (or if need be tacotime or fluffypony).

I do not have time to read various Monero research papers and otherwise dig to see if the following concern is already addressed.

I am concerned about a hole in the anonymity of Cryptonote ring signatures. I had sort of described this issue to smooth (who apparently relayed it to all) when I was contemplating ways that BCX might unmask the anonymity of users. I do not recall if I made this specific weakness explicit as follows.

If the actual input to a transaction (in Monero terminology this is the output of the prior transaction) is not also an input to another transaction's ring signature (and when all the other inputs to the ring are spent) or if it is also the input to a subsequent ring in which all the other inputs were outputs created after the said transaction was created, then the anonymity of the said transaction is entirely unmasked.

Combinatorial trees can be searched as well, thus even if only some of the other inputs were outputs created after the said input was created, this could cascade into unmasking the anonymity or at least reducing the anonymity set. And note the anonymity set also vulnerable to further reduction by out-of-band attacks such as IP de-obfuscation, rubber hoses, stolen private keys, hacked users, etc.

There are some tweaks that need to be made to insure the above is unlikely. Hopefully Monero is enforcing some restrictions already on which outputs can be used in ring inputs? If not, they need to get on it pronto.

P.S. for those who thought I wasn't sincerely attempting to help Monero during the BCX incident, I hope the above satisfies you. I think before I had an agreement with the Monero devs (via smooth) not to write publicly all the details of the above weakness in order to give them time to address it. I think they've had sufficient time and I want to make sure this is addressed.

TPTB_need_war, I'm a little confused by your comments here, :

"If the actual input to a transaction (in Monero terminology this is the output of the prior transaction) is not also an input to another transaction's ring signature (and when all the other inputs to the ring are spent) or if it is also the input to a subsequent ring in which all the other inputs were outputs created after the said transaction was created, then the anonymity of the said transaction is entirely unmasked."
[

could you explain how an input to a transaction is not also an input to another transactions ring signature when other inputs to the ring are spent? Specifically, how do you know the other inputs are spent, if they are also in ring signatures? (Ofc all other inputs could be sent with 0-mixin, but fluffyponyza has mentioned that this is in MRL004, and will be modified in a upcoming fork (for example mymonero forces min-mixin 3).

Also in your second sentence (sorry it's a little hard to parse), "[if actual input to a transaction]

is also the input to a subsequent ring in which all other inputs were outputs created after the said transaction was created

," how do you know in the subsequent (or initial ring) that said input is not being grabbed ad-hoc from another user as a decoy input for both the initial and subsequent ring without knowing which inputs have actually been spent?

could you please help me out by perhaps giving an example of how either of these would work (disregarding the 0-mixin case which has been addressed by fluffypony  / mrl-004)

(unless you have some way of telling whether outputs have been spent, thus proving the proofs of Fujisaki/Suzuki https://eprint.iacr.org/2006/389.pdf incorrect, what you suggest seems impossible to me). Ok - I see there is an error in this logic.. in FS, they don't have any additional data about the ring itself (like inputs / outputs) so perhaps with some graph analysis with this might be possible.. -I don't think it would be a difficult fix if this was possible however, you just need to compute the graph of the people you are mixing with and make sure there are no loops.. (if the graph gets too big, pick a new ring)..

Someone was kind enough to ping me in private to come back here. Otherwise I wouldn't have seen this. I am not reading this thread normally.

What I was getting at is the ordering that transactions appear in the block chain. I provided some examples where combinatorial analysis has whittled done the anonymity set such that you have transaction in which all the inputs to a ring have been included in enough rings (taking into account all other inputs to those rings) that it is known that all those inputs have been spent, but it is not known which input is the spender to each of the said rings.

From there are ways to isolate which input is the spender.

1) If the last use of one the inputs is in a ring includes only other inputs that already reached their saturation (or any smaller set say just two of inputs that didn't reach saturation), then we know that said input is the spender (or know the spender is one of the smaller set of unsaturated inputs). Here is an example in chronological order:

Ring 1:
I0, I1, I2
Ring 2:
I0, I1, I3
Ring 3:
I0, I2, I3
Ring 4:
I1, I2, I3
Ring 5:
I2, I3, I4  ------> I4 is surely the spender

2) The second case I wrote was indeed difficult to parse because it was incorrect. I believe I was thinking about how to insure the overlapping in #1 doesn't occur and afaics that requires deciding which outputs must be mixed with which outputs before any ring with those outputs has been created. I apparently conflated those thoughts when trying to contemplate the explanation of a case where combinatorial analysis unmasks the anonymity such as #1 above.

The worst thing that can happen to me is that I'm "disappeared", but that's why the core team is seven strong:)

What if you "disappeared" and because of that the other 6 "retire" or "lose interest" and turn over control to "Gavinmike".

Much better the code was done and locked in stone. But I know that is very difficult to achieve at this experimentation stage.

Sufficed to say your "cooperation" would not go so far as to backdoor anything or use libs you otherwise would not have, correct?

That's why it's OPEN SOURCE.

Sometimes even that isn't enough:

https://www.schneier.com/blog/archives/2006/01/countering_trus.html

[ray88]

Hi there i have xmrchat.com and monerochat.com for sale
pm me your offer

[myagui]

@fluffy @smooth & co,

The pools section in the OP would do well with a wee bit of house keeping.
I've checked each pool link to find the following:

http://backup-pool.com/monero/  <- dead link
http://monero.backup-pool.com/  <- current link

http://pool.cryptoescrow.eu/   <- dead link, pool closed

http://monero.coolmining.club/  <- pool closed

Cryptonotepool.uk is listed as donating 0% of their fees, which I understand is not the case.
I think there are also new pools to be added, though I don't have the necessary info.

Cheers!

[MoneroMooo]

Here's a less technical overview of what's been pushed to Monero. Since I'm starting, I'll just do the first history page from github, which covers about a month: https://github.com/monero-project/bitmonero/commits/master

There's been a fix for EOF (end of file) input, over several pull requests, which allows simplewallet and bitmonerod to exit normally when ^D is pressed. This may seem esoteric to Windows users, but it's a common way to end input on Linux, and it was bugging me that when I did that, simplewallet went into an infinite loop failing to read, and I had to ^C it. So that's now fixed.

Next, we've got a fix to a socket (network connection) count. As far as I can tell, there is no real user level fix here, it was just an informative count, and the counter wasn't properly maintained when a connection was closed. If nothing else, it should be less confusing now when debugging this code.

Watch-only wallets were previously saved using the same password as the original wallet. This is now changed, so an independent password can be used. This is useful if you're going to send that watch-only wallet file to someone else: they won't get your main wallet's password.

Integrated addresses allow the merging of a standard address with a payment ID in a single serialized larger address. It's using base58 with checksum as well. This allows someone to give a standard address + payment ID pair with a single user string, which may hopefully mean easier integration in existing processes. There are RPC commands as well to manipulate those so exchanges/services can use them in scripts.
There will be an update to that soon (hopefully) which will allow these payment IDs to be optionally encrypted on the blockchain as well - currently, they're in cleartext.

A bug in the checkpoint loading from DNS got squashed. It wasn't correctly walking the list of DNS servers to compare their results and look for matching records, to mitigate corrupt/malicious data being received from a minority of them.

Transaction splitting (when you send some amount, but the list of inputs is too large to fit in a single transaction) now handles much larger splits, and will split very large transfers a lot quicker. Instead of trying to split in 1, 2, 3, 4, 5, etc transactions, it will use an exponential curve, so when at first it doesn't succeed, it starts taking larger steps. Reasonably sized transfers that fit in 3 transactions or less will still take as little as possible.

Seed related commands (or some of them) are now disabled for watch-only wallets, where they don't make much sense.

Watch-only wallets can now be created from a standard address and a view key (they were previously created by saving a wallet from an existing full wallet in simplewallet). This makes it much easier to use a view key (ie, the Monero core team publishes their standard address and view key).

DNS results could previously ignore the fact that a result came from a server without cryptographic assurance of non tampering. This was changed so that crypto proofs of results is required. I'm not 100% sure what kinds of failures were being disregarded here.

Non ASCII mnemonic seeds were mishandled in simplewallet, which would mean a seed generated from the offline wallet generator would fail to restore in simplewallet. This was fixed, and non English languages could then be enabled in the generator.


And that's it for last month.

[smooth]

What if you "disappeared" and because of that the other 6 "retire" or "lose interest" and turn over control to "Gavinmike".

Then someone else can fork the repo and take over. If no one cares enough to do that, then it doesn't really matter does it?

If you are asking for some sort of ironclad guarantee of no potential failure modes of an asset with potential million-to-one returns in the event of meaningful success then you don't really understand economics, and I don't think that is the case. I guess you are just pointing out possible failure modes for others, which is fair game.