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

[equipoise]

//offtopic. I'll delete it if against the rules.

We are raising donations for this campaign. There are already 351$ and 0.0403 BTC in donations for Bojia:
"The 80 years old mother Bojia Bikova was accused of growing hemp by the Bulgarian police, who found a few uprooted sprigs of hemp in her field in the countryside. She was sentenced to pay about $1100 including court taxes. The monthly pension of old mother Bojia is $100. The amount she has to pay is close to the full amount of her pension for the whole year."
You could watch a short video about her case here: https://www.youtube.com/watch?v=gqmGkti9uUQ.
I created an XMR address for this campaign. Please support it. If in doubt about the validity of the address, I could ask our admin to add an OpenAlias XMR address to promena.org:

Code:

49bXbjMqAGmQCApWssWKMd9pnMq2AnExkUCrajnAeGM6dsJNagvwCd8VQxVWs3gamMQTxWirG9yrEeKpSocFyTGbH4TEvu4

//offtopic

This may be the first non-governmental organization accepting Monero donations for its campaigns. We added OpenAlias xmr address to promena.org. It seems that the domain registrar is not adding TXT DNS records correctly with their GUI. They are adding "invisible spaces" like the space in the Monero address in bitcointalk (you could see the spaces here - type promena.org and select TXT record: http://manytools.org/network/query-dns-records-online). The result is that you can't add a valid OpenAlias address (or any valid long words TXT record). How many domain registrars are out there which are doing the same?

The domain registrar fixed their bug and the OpenAlias address promena.org is now working for the "Bojia" campaign. My contribution is 20 XMR. I'll make sure the total sum of Monero donations is cited at the end of the campaign and I'm pretty sure a successful campaign will catch some media attention (Bulgarian media are already following the "Bojia" case).

OpenAlias Monero address added to promena.org for the "Bojia" campaign. You could now send XMR to promena.org - there are 107 XMR in donations till now.

Donation of 25 XMR just sent

Great. Thank you! We are at 371$ + 134 XMR + 0.0402 BTC. 12 days left till the end of the campaign.

USD: Indiegogo - https://www.indiegogo.com/projects/help-old-mother-to-pay-her-fine-for-hemp-possesion--2#/
BTC: Bithope - https://bithope.org/campaign/help-the-old-mother-bojia-campaign/
XMR: promena.org (OpenAlias address)

[1715110998]

1715110998

[1715110998]

1715110998

[1715110998]

1715110998

[medusa13]

https://www.youtube.com/watch?v=mLWhU3f0xlc&feature=youtu.be&t=27m14s

i have this idea for long time with monero. its not so important now, but no one can really predict how monero will perform under load. so better we find out.
does anybody know how they do it in bitcoin? do they even have this kind of setup?

would love to help build this up synthetically, maybe so that it can be repeatet without burning too much money all the time. sure we would need help from devs for this, a special fork with premine that we flush again would maybe be best? or are there other ways to do it?

how many nodes? how strong would they need to be with what kind of connection? what about the spammers, how much

all bullshit? good idea? please tell

btw check the very nice question in this video too: https://www.youtube.com/watch?v=mLWhU3f0xlc&feature=youtu.be&t=30m51s

the answer is simply: MONERO (but no mention at all)

someone should send him an email

[GingerAle]

https://www.youtube.com/watch?v=mLWhU3f0xlc&feature=youtu.be&t=27m14s

i have this idea for long time with monero. its not so important now, but no one can really predict how monero will perform under load. so better we find out.
does anybody know how they do it in bitcoin? do they even have this kind of setup?

would love to help build this up synthetically, maybe so that it can be repeatet without burning too much money all the time. sure we would need help from devs for this, a special fork with premine that we flush again would maybe be best? or are there other ways to do it?

how many nodes? how strong would they need to be with what kind of connection?

all bullshit? good idea? please tell

totally doable. Monero has a testnet. It would just require getting a bunch of testnet coins, which are really easy to get. I have 10s of thousands! Fluffy's a testnet millionaire.

So you'd just get a bunch of vps all over the world, load up testnet daemons, make scripts to mimic real world activity, and then watch the adaptive blocksize grow.

in essense, we already watched monero perform under load with the block 2610212098473097403232 whatever the hell it is attack. And good for it, because that attack broke monero, and then it was fixed, so yeah. This kind of stuff is useful!

Hah, at 31:60 they talk about privacy.

MONERO!!!! I JUST WANT TO SHOUT MONERO!

[medusa13]

totally doable. Monero has a testnet. It would just require getting a bunch of testnet coins, which are really easy to get. I have 10s of thousands! Fluffy's a testnet millionaire.

So you'd just get a bunch of vps all over the world, load up testnet daemons, make scripts to mimic real world activity, and then watch the adaptive blocksize grow.

in essense, we already watched monero perform under load with the block 2610212098473097403232 whatever the hell it is attack. And good for it, because that attack broke monero, and then it was fixed, so yeah. This kind of stuff is useful!

Hah, at 31:60 they talk about privacy.

MONERO!!!! I JUST WANT TO SHOUT MONERO!

i somehow think testnet is not the right place to do it..we should not ruin the testnet chain that has (will have?) a hard fork inside and many different kind of transactions with a lot of spam.
the testnet chain is valuable because it has history inside. this helps when testing other stuff. but for load testing we dont need this
but maybe i could be wrong

[dEBRUYNE]

AMA on Roger Ver's http://forum.bitcoin.com with our core team member Riccardo "fluffypony" Spagni: https://forum.bitcoin.com/ama-ask-me-anything/i-m-riccardo-fluffypony-spagni-of-the-monero-core-team-ask-me-anything-t2872.html

[myagui]

AMA on Roger Ver's http://forum.bitcoin.com with our core team member Riccardo "fluffypony" Spagni: https://forum.bitcoin.com/ama-ask-me-anything/i-m-riccardo-fluffypony-spagni-of-the-monero-core-team-ask-me-anything-t2872.html

Nice one! I've asked the question that everyone had but never voiced btw (#3), waiting for a reply 

[sulfurtank]

https://www.youtube.com/watch?v=mLWhU3f0xlc&feature=youtu.be&t=27m14s

i have this idea for long time with monero. its not so important now, but no one can really predict how monero will perform under load. so better we find out.
does anybody know how they do it in bitcoin? do they even have this kind of setup?

would love to help build this up synthetically, maybe so that it can be repeatet without burning too much money all the time. sure we would need help from devs for this, a special fork with premine that we flush again would maybe be best? or are there other ways to do it?

how many nodes? how strong would they need to be with what kind of connection? what about the spammers, how much

all bullshit? good idea? please tell

btw check the very nice question in this video too: https://www.youtube.com/watch?v=mLWhU3f0xlc&feature=youtu.be&t=30m51s

the answer is simply: MONERO (but no mention at all)

someone should send him an email

Judging by all of these agencies jumping on board so briskly, this has been cooking for quite some time now... We should be looking at past moves made by any of the agencies, especially devs and btc companies!

[iCEBREAKER]

Nobody cares about Bitcoin Judas's rump forum (nice Digg button lol) so I'll shovel the Good News over here.

Myagui wrote:
Do you have long term plans concerning your particular collaboration in the Monero project or any other/new initiatives in the pipeline?  (other than MoneroDice & MyMonero)

fluffypony wrote:
Yes - I have several projects up my sleeve that I'm working on. Almost all of them are services for both Monero and Bitcoin, as I don't believe that Bitcoin must fail for Monero to succeed (quite the opposite). A few of these projects are finally nearing completion, so hopefully there will be a few more product launches in the next couple of months!

 

jwinterm wrote:

I think I heard someone mention that there wouldn't be any serious work on I2P integration until they (I2P) had a stable release, but looking at their wiki it says "I2P has had a stable release every six to eight weeks." So, does that mean there won't be any integration work until they release I2P v1.0 that is long term stable? Do you have any idea how far out on the horizon that might be?

fluffypony wrote:

The issue wasn't if I2P in general was stable, the Java router is definitely stable enough. The issue was that we didn't want to add Java as a dependency for running Monero, so our focus has been on a C++ implementation of the I2P router. Expect a big announcement on this in the next couple of weeks 

 

pa_ wrote:

Why use Monero instead of Dash or Zerocoin/Zerocash? Aren't they just as private?

fluffypony wrote:

Whilst not wanting to turn this into a this-currency-vs-that-currency debate, I will answer this, as I think it's important to understand the proverbial lay of the land.

Designing a cryptographically sound solution to a privacy problem is seriously difficult. As Greg Maxwell puts it, "information wants to be free", and the weakness will always be the human element. The more heavily reliant your scheme is on the opsec of participants, the more prone to leaks it will be. Coupled with this is the problem of "thinking adversarially", which is something that goes deeply against our human nature. To illustrate how flawed our human reasoning is when we try to think adversarially: if a Bitcoin node can only connect to 8 peers, how many of those have to be honest for the node to determine which ones are dishonest? As a human you might reason "well, if 4 are honest, and 4 are dishonest but telling the same lie, it can't tell which is honest, so the answer has to be 5". Or maybe you'd reason that dishonest peers will mostly be telling different lies, so if eat least 2 agree then they must be the honest ones...right? The actual answer is 1. It only needs 1 honest peer to be able to determine that the rest are dishonest. This is because it follows the "longest chain with valid PoW" rule, and can rule out all other nodes as offering dishonest chains. Now knowing that most of us are so incapable of designing such an elegant solution, and our minds resort to broken and hacky things like "voting", we should immediately be suspicious of any and all new systems and schemes. This is especially true where they are promising something as sensitive as privacy, and where there is money to be made (pretty much unique to altcoins, no new open-source reverse proxy or database or other project has the potential to make money for its creator).

Dash fails because, as djb describes in this excellent recent article, they have an "attacker economist" approach.

In other words, instead of purposely designing their systems to be cryptographically sound so that the "attacker will definitely fail" or the "attacker will probably fail", they instead (unwittingly?) design it so that "the attacker's expected cost of carrying out an attack exceeds the attacker's expected benefit from doing so." The unfortunate knock-on effect is that such an approach only works like that for a limited time...as the value of the cryptocurrency grows, so does the level of sophistication of the attackers that find it an interesting target. Trying to solve the privacy problems in a way that relies on the honesty and opsec of a small group of individuals is simply privacy theatre, no different from those that claim that Bitcoin is private as long as there's no address reuse.

On the other end of the scale is ZeroCoin, which is about as sophisticated as you can get, and in my opinion represents the future of cryptocurrency systems. In fact, it's sophistication is also its largest problem: the cryptography behind it needs a significant amount of peer review, and and implementation needs a significant amount of vetting, else you may end up with an exploitable bug where someone can double spend, or create a large number of coins, and nobody will be able to see it. In my mind I would need to give it 20-30 years before I could trust it with my livelihood.

Dash 

[Hueristic]

Hey any of you guys got any trust or opinions on this?

https://bitcointalk.org/index.php?topic=1216479.0

[primer-]

Monero bagholders should read this :
https://www.reddit.com/r/ethereum/comments/3tappe/early_alpha_monerolike_linkable_ring_signatures/

Make sure you read the post by fluffypony :
https://www.reddit.com/r/ethereum/comments/3tappe/early_alpha_monerolike_linkable_ring_signatures/cx55kp2

Riccardo, you retard.

I'll be dumping my XMR in favour of ETH soon, its been deprecated

[binaryFate]

I'll be dumping my XMR in favour of ETH soon, its been deprecated

As I said on reddit:

since their language is Turing-complete it's obvious they can implement everything that can be implemented in other cryptocurrencies (and generally on any computer), so it's a bit of a non-news per se. The interesting question though is what performance/cost do they pay compared to a "native" solution. This is all about trade-off, and that one might be a painful one.

[primer-]

As I said on reddit:
since their language is Turing-complete it's obvious they can implement everything that can be implemented in other cryptocurrencies (and generally on any computer), so it's a bit of a non-news per se. The interesting question though is what performance/cost do they pay compared to a "native" solution. This is all about trade-off, and that one might be a painful one.

The only trade-off is that it will be possible to tell the coins went through a mixer at one point in time. Works for me.
Monero can't compete with ETH, I'm not sure bitcoin can either.

[dEBRUYNE]

As I said on reddit:
since their language is Turing-complete it's obvious they can implement everything that can be implemented in other cryptocurrencies (and generally on any computer), so it's a bit of a non-news per se. The interesting question though is what performance/cost do they pay compared to a "native" solution. This is all about trade-off, and that one might be a painful one.

The only trade-off is that it will be possible to tell the coins went through a mixer at one point in time. Works for me.
Monero can't compete with ETH, I'm not sure bitcoin can either.

You forget that fees have to be paid using transparent coins.

[primer-]

As I said on reddit:
since their language is Turing-complete it's obvious they can implement everything that can be implemented in other cryptocurrencies (and generally on any computer), so it's a bit of a non-news per se. The interesting question though is what performance/cost do they pay compared to a "native" solution. This is all about trade-off, and that one might be a painful one.

The only trade-off is that it will be possible to tell the coins went through a mixer at one point in time. Works for me.
Monero can't compete with ETH, I'm not sure bitcoin can either.

You forget that fees have to be paid using transparent coins.

Why would that be a problem ? Anyway, do you own research people.

[dEBRUYNE]

As I said on reddit:
since their language is Turing-complete it's obvious they can implement everything that can be implemented in other cryptocurrencies (and generally on any computer), so it's a bit of a non-news per se. The interesting question though is what performance/cost do they pay compared to a "native" solution. This is all about trade-off, and that one might be a painful one.

The only trade-off is that it will be possible to tell the coins went through a mixer at one point in time. Works for me.
Monero can't compete with ETH, I'm not sure bitcoin can either.

You forget that fees have to be paid using transparent coins.

Why would that be a problem ? Anyway, do you own research people.

Because a blockchain observer could see which address paid fees to mix his coins. It should also be noted that it's in early alpha stage, see following quote as well:

# TOTALLY NOT TESTED AND LIKELY BROKEN AT THIS POINT; AWAITING A TEST SUITE

That said, it's an interesting development and it also gives some credibility to the protocol Monero is using.

[digicoin]

Why would that be a problem ? Anyway, do you own research people.

You seems not to be a coder right? I read ETH's source code for XMR-like smart contract. It is so funny although I know it is just a basic code to demonstrate a proof of concept. If you are able to read the source code, you will not be so confident. I know developers are kings because they can say anything that everyone who can not read source code has to believe.

[SecretsCoin]

Why would that be a problem ? Anyway, do you own research people.

You seems not to be a coder right? I read ETH's source code for XMR-like smart contract. It is so funny although I know it is just a basic code to demonstrate a proof of concept. If you are able to read the source code, you will not be so confident. I know developers are kings because they can say anything that everyone who can not read source code has to believe.

it does not matter who they are , just enjoy it

[newb4now]

New git updates since last time:

- blockchain_export can now create files compatible with NoodleDoodle's fast sync code
- speedup for the one-time database rescan to initialize hard fork into
- database dump utility, intended to detect differences between the several blockchain formats
- a new status command in the daemon, giving more user oriented information
- and random other fixes for DB potential issues, some RPC commands not working properly

Git updates since last time:

- simplewallet can be set to use a different default mixin than 4 (eg, set default-mixin
- more hardfork voting changes: first hard fork will not be voted on, due to complicated issues with alt chains
- block time change from 1 minute to 2 minutes (to take effect at the next fork)
- new show_transfers simplewallet command, to show in/out transactions in a more user friendly way
- more daemon commands now work again on the development branch, using 0MQ

Will there still be a minimum mixin number in the new release? I like the idea of a minimum mixin but what impacts if any will this have on pools and or exchanges that must deal with dust transactions?

[smooth]

New git updates since last time:

- blockchain_export can now create files compatible with NoodleDoodle's fast sync code
- speedup for the one-time database rescan to initialize hard fork into
- database dump utility, intended to detect differences between the several blockchain formats
- a new status command in the daemon, giving more user oriented information
- and random other fixes for DB potential issues, some RPC commands not working properly

Git updates since last time:

- simplewallet can be set to use a different default mixin than 4 (eg, set default-mixin
- more hardfork voting changes: first hard fork will not be voted on, due to complicated issues with alt chains
- block time change from 1 minute to 2 minutes (to take effect at the next fork)
- new show_transfers simplewallet command, to show in/out transactions in a more user friendly way
- more daemon commands now work again on the development branch, using 0MQ

Will there still be a minimum mixin number in the new release?

There will be a minimum but it won't be enforced by the network until the fork in the spring.

I like the idea of a minimum mixin but what impacts if any will this have on pools and or exchanges that must deal with dust transactions?

There are various changes to how dust works that should address this. There is also an exception for dust that isn't mixable (but new unmixable dust won't be created, so eventually the exception will disappear from the network as the old dust is used up).

[newb4now]

New git updates since last time:

- blockchain_export can now create files compatible with NoodleDoodle's fast sync code
- speedup for the one-time database rescan to initialize hard fork into
- database dump utility, intended to detect differences between the several blockchain formats
- a new status command in the daemon, giving more user oriented information
- and random other fixes for DB potential issues, some RPC commands not working properly

Git updates since last time:

- simplewallet can be set to use a different default mixin than 4 (eg, set default-mixin
- more hardfork voting changes: first hard fork will not be voted on, due to complicated issues with alt chains
- block time change from 1 minute to 2 minutes (to take effect at the next fork)
- new show_transfers simplewallet command, to show in/out transactions in a more user friendly way
- more daemon commands now work again on the development branch, using 0MQ

Will there still be a minimum mixin number in the new release?

There will be a minimum but it won't be enforced by the network until the fork in the spring.

I like the idea of a minimum mixin but what impacts if any will this have on pools and or exchanges that must deal with dust transactions?

There are various changes to how dust works that should address this. There is also an exception for dust that isn't mixable (but new unmixable dust won't be created, so eventually the exception will disappear from the network as the old dust is used up).

Thank you! Glad to hear we will have both a minimum mixin and a long term solution to the dust problem