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

The reason the defaults are best kept low for now is that the syncing part of the p2p code is currently quite inefficient.

If you allow it to use more bandwidth, it wastes disproportionately more bandwidth (by downloading the same block multiple times), including from peers who have graciously donated their upstream bandwidth. Somewhere on the development plan is a goal to replace it with a better and more maintainable implementation, although I don't rule out that useful tweaks are possible too.

If it were just a matter of trading more bandwidth over a shorter period of time for less bandwidth over a longer period of time, then a download limit wouldn't really make sense at all, but that's not the case.

In terms of address on the blockchain, yes it will be different. The public stealth address (which doesn't appear on the blockchain) can be the same.

For the hash->payment ID method, the address doesn't matter, and that is the motivation behind it. Searching for a specific payment IDs is possible so any transaction on the blockchain (with whatever address) using the payment ID after the hash is published will suffice.

I didn't mention earlier that you should ideally publish the unhashed payment ID after the transaction is confirmed. This isn't entirely required because someone could scan the entire blockchain (after the original hash publication time), hashing each payment ID looking for a match. But it is easier to just publish the unwashed payment ID.

Because of the possibility of reorgs or transactions confirming out of order this method isn't entirely secure. Someone could see the transaction being sent, compute and match the hash, and then send a smaller transaction using the same payment ID to call into question which is the real proof. To avoid that you can append a secret to the payment ID before hashing it, then send the payment, wait for it to be sufficiently confirmed, then reveal the secret (and optionally the payment ID).

I agree with luigi1111 that this method isn't idea for cold storage and using validated key images is better.

Sure it does. Or it should. I think there may have a been a recent bug near head, but there's no technical reason why you can't.

As far as proving solvency: using the viewkey functionality in simplewallet (while really cool!) for something like safedice isn't that practical, as every "auditor" would have to input your information, then spend minutes of processing time to detect all your outputs, only to find they don't actually know the state of your account because they can't reliably detect spends.

Smooth's idea of publishing a pID hash prior to sending a TX would work well, though you'd want an easy way for folks to do the hash themselves (probably in Javascript).
Similarly, I have a page that can "decode" the stealth addresses for a tx, which would essentially accomplish the same thing.

Passing *all* of your funds around regularly of course isn't ideal in either case (cold storage and all that).

If you have a decent amount in cold storage that likely stays untouched for long periods of time, then providing signatures validating the key images for the outputs in question would be more ideal (need a way to generate these signature and also an API to check the key images against).

Yeah instead of a "config" file, just launch with a batch file or shell script.

Edit: I also agree 128 KBps is quite low for initial sync. 128 KBps upload on the other hand will likely be too high for many home connections.
FWIW, I believe some "reasonable" limits should be in place by default, but perhaps it should be a bit more publicized that they exist and how to change them (though it is obvious from --help).

Crosspost from another thread:

or just type limit 999 into the daemon console, or start up bitmonerod with some limit flag "--limit-rate 999"... or put the CLI command mess into a script and then run the script.....

https://www.youtube.com/watch?v=NQ-8IuUkJJc

Who can I get a quote from, and possibly pay, to submit a PR for "last post submitted by *name* on *date+time* added to both the sections and sub sections for the official forum, in addition or in replacement to the last *author* and *date+time* a thread was opened (this is already there)?

I'm looking for the additions here: https://forum.getmonero.org/

and here, for each subsection: https://forum.getmonero.org/1/news-announcements-and-editorials   ...   https://forum.getmonero.org/21/the-thread-cemetery

More about lack of a config file. You have to plaster the binary with command line arguments. Not everybody's favorit.

That is good idea, to publish the PID hash before the transaction to prove solvency. Although we have to send it to separate address each time we want to do that, right? Monero doesn't allow sending coin to the same address.

New version of the monero wallet generator at https://github.com/moneromooo-monero/monero-wallet-generator.

It can now display seeds in Japanese and Spanish (you will need my latest patch to simplewallet to restore them, however. Moreover, it might not work yet on Windows, I'm told there are UTF-8 issues there with the seed).

GPG verification instructions are now on the page, and a standalone signature is there for those who do not get the file from git.

And last but not least, there is a vanity address generator
It's pretty basic, and does not check whether a particular prefix makes any sense (yet).
Chances are pretty good it'll be pretty slow though. So to get a sense of how fast it goes on your CPU, try it first with a small prefix. And remember that it it's a prefix that can't be generated for an address, it'll never find a suitable address.

its working 

Should be working fine now!

When we didn't have QoS then we had people complaining about the bandwidth usage. Now we have QoS and a sane bandwidth limit, and people are complaining about it not using enough bandwidth:-P

If I'm not mistaken , Othe can translate English to German. https://bitcointalksearch.org/user/othe-265368

Not in german obviously but if you want a quick explanation of how Monero works fluffypony explained it very well at the Bitcoinference: https://youtu.be/GEVm1dMn5Ks?t=1132

He probably wants to know in which way and why Monero is not affected by the sophisticated chainanalysis Elliptic is performing.

Hi, I am referring to this:
http://cointelegraph.com/news/114604/good-bitcoin-bad-bitcoin-blockchain-analytics-and-fungibility

We (cointelegraph.DE, so the german site) are writing an article about it as well and I`d like to have a "soundbite" to quote in this context (quoted from the article above):

"“Hence my view,” says Vays, “that if bitcoin becomes legal and controlled, there will be an anoncoin that will rise to the top and be 30 to 40% of Bitcoin market cap, and many useless jobs in the government will be added to endlessly fight against it."

Sorry if I appear ignorant, but what are you referring to? The release of their "big bang" product? What does it have to do with Monero and German?

You shoud shoot othe (https://bitcointalksearch.org/user/othe-265368) a PM to see if he is willing to do this. He is one of the core team members and speaks German. I also send him a message so that he is aware of your request (not sure if he has seen it yet).

EDIT: In addition, try #monero or #monero-dev on freenode, he is there most of the day(s).

Any german speaking Monero Dev able to give a short comment on the Elliptic announcement and why XMR is not affected?
Preferably in German and in a short way a noob could understand?
Need a quote for a german article about Elliptic and why Anoncoins could benefit.