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

Monero Missives

July 23rd, 2014

Hello, and welcome to our eighth Monero Missive!

Major Updates

1. We're extremely pleased to announce that Poloniex has, once again, proven their class-leading initiative by being the first major exchange to add Monero trading pairs. This has been coming for a while, given Monero's large trade volume on Poloniex, and we are certainly grateful to Poloniex for their forward-thinking approach. The markets that have been added are: BCN/XMR, DIEM/XMR, DRK/XMR, IFC/XMR, MAID/XMR, NXT/XMR, and QORA/XMR. The Poloniex press release can be found here.

2. A major change that has been made concerns the license Monero currently uses. We inherited the MIT / X11 license from CryptoNote, which is a very permissive license that explicitly allows re-licensing with compatible licenses. We have thus decided to move to the BSD 3-clause license, which is equally permissive, enforces attribution, and has a clause that prevents "the name of the copyright holder nor the names of its contributors" from being used to promote or endorse products. The epee library that is part of Monero was already under a BSD 3-clause license, so all we have done is just replaced it with the standard formatting we're using, and have included the original in the /contrib/epee/LICENSE.txt, noted as being the original license as it appeared. We have taken great care to preserve ALL copyrights for the original code, which are attributed to "the Cryptonote developers" for most of it, and "Andrey N. Sabelnikov" for epee. Our copyright appears above that so that we are the copyright holders for any new code. Any brand new files that are added by us will not get any copyright attribution except ours (eg. electrum-words.h and .cpp that have been added by us).

   For public domain code we have left the license as is (much of the crypto hashing code, for instance). If you spot ANY code where the original author has not been credited or copyright has not been retained, please let us know by opening an issue on Github or messaging or emailing us.

3. Along with this change is a new README, that should be a little better at giving the correct build instructions, as well as explaining the development rationale and a more formal staging -> tagged release methodology we will be using moving forward.

4. Since git (and, by extension, github) can be confusing to developers that are working on Monero code (or on any git repositories, really), one of the Monero key contributors, tewinget, will be hosting a Git Crash Course next week Wednesday, July 30th. He will be joined by fluffypony, and all interested are invited to attend. It will be broadcast through Twitch, and questions and discussions will happen in #monero-dev on Freenode during the course. It's going to be relaxed and informal, so if you want to know how to use git properly it's well worth tuning in. It will start at 2pm EST (6pm UCT). Feel free to invite anyone that you think will benefit from it!

Dev Diary

RPC: a new RPC call has been added to the daemon, get_info. This returns information on the current state of the daemon and the network, including the current block height.

RPC: the new get_bulk_payments RPC call is complete and available. Apart from being able to pass thousands of payment IDs to this function, you can optionally pass a block height, and it will scan from the block height up. To give you an indication: Poloniex went from taking nearly 45 minutes to scan all of their payment IDs with get_payments, to it taking around 17 seconds with get_bulk_payments.

Core: the major change of introducing rpcwallet, as well as proper daemonization / service mode (on *nix or Windows respectively) is ready for testing. If you are able to, please compile and test this branch so we can finalise it and merge it in: https://github.com/mikezackles/bitmonero/tree/daemonize_wip

Until next week!

- updated by fluffypony

Excellent!  

Yay!!!

I understand that for the transactions from a pool to my local wallet, but not for a transfer between two of my own wallets. Thanks for the help.


The idea is to at some point move to a much newer wallet with deterministic seed and new password, and clean up dusty transactions along the way. If that's achievable without a transfer I'm open to alternatives.  

We did already, but I didn't like the way that was implemented (it looks like it spins up internal testnets more akin to regression testing). I already wrote up some specifications for a Bitcoin-style testnet, so we have something operational for lots of people to play with along the lines of bitcoin testnet3.

In the testing suite there already is something very similar to a regression test anyway, that just needs to be fixed.

Why don't you plagiarire testnet from CryptoNote?
https://github.com/cryptonotefoundation/cryptonote/commit/f4769d87ad606b63484ef76ef57f50b5ac117d0a

XMR markets live on POLO guys

https://www.poloniex.com/press-releases/2014.07.23-Poloniex-Welcomes-New-Monero-XMR-Markets

We are trying to. We don't even have a proper testnet functioning, which makes things difficult. I added a note to the repo in issues a while ago for the addition of a testnet and the fixing of the test cases from the original ByteCoin code (most of which are now broken).

It's difficult. I code full time on another project, we only have a few dedicated, paid f/t devs at this point, and we're constantly trying to implement new things that have been requested by exchanges and others. I'm around to talk to if people want to hack on the project and have been working with the f/t devs to try to get out majorly needed features like an actual database, and I've been emphasizing fixing the testing suite for a while now.

Nicely said. It just makes me sick when some devs claim to be superior but can't deliver and make silly but fatal bugs. Hopefully, this story will end up with the right conclusions for the core team.

Making a mistake is not childish.  It's human, and it happens to everyone.  Casting the first stone and all that.  It doesn't matter if the mistake is apparently simple or not.

The test in this is whether the Monero team addresses it in an adult way:  Will they add tests and/or procedures to *prevent this same kind of error* from getting introduced again?  Will they communicate that they've done so?

I suggest taking a chill pill and checking back after the dust has settled instead of pointing fingers and calling people names.

Here's a nice bitcoin bug from last year to ponder:  http://ecurrency.ec/2013/03/bitcoin-bug-resolved/

If there aren't improvements made to, e.g., regression and acceptance testing, as a result of this, then make noise.  But adding that and doing an adult post-mortem of what went wrong takes longer than a few hours when your development team is small and scattered around the world.

It's wonderful to see how Monero PR team works. Everytime there's a painful topic in this thread, some new members arrive and start posting irrelevant bullshit. You're doing great guys!

Come on, proof-of-haiku, really? The "core team" failed for several weeks and potentially exposed every XMR user with a bug leading to money loss. Could you make a haiku on that?

100 XMR bounty for open-source Proof-of-Haiku!

I think there's also a 50 XMR bounty for an open-source Cryptonight abacus, still waiting to be claimed also!

Why don't you just copy wallet.dat or import private keys than transferring it?
Kindly,
        MZ

Awesome survey, can't wait to see some of the results!


The tx fees do not go to the devs.

Thank you Minergate for helping out incompetent XMR developers. They should be very grateful this was fixed so fast, could've been much worse.

Imagine what would happen if this went unnoticed - a lot of people with a lot of lost funds all due to a childish mistake.

dnote has had quite a few replies and I very happy with tacotime's response, very professional.

On the other hand, you're being very childish.

Transaction fees are going to the miners - when you are mining for a pool it's distributed to all the pool miners depending on their hash power (when the pool fee is subtracted).

I love how all monero shills now sit tight and don't post shit. Quite... can hear birds singing. I like that.

This is true. Today we at MinerGate updated our XMR daemons and wallets to the latest github version, but fortunately the wallet didn't pass our sanity check tests, because of PaymentID being skipped for every tx.

I've created a pull request with a fix, please take a look.
https://github.com/monero-project/bitmonero/pull/69

UPD: fluffypony accepted my request, thanks!