No, malleability doesn't lead to a malformed signature. A malformed signature would be invalidated by virtue of it being malformed. With a traditional Bitcoin malleability attack you change the signature format on a tx and rebroadcast it, but the signature remains perfectly valid. The bulk of the anti-malleability changes in 0.9.0 are around things like listreceivedbyaddress or getbalance or listtransactions RPC API calls to make them less error-prone. There is a slight tightening of IsStandard() to make rebroadcast of modified transactions harder, but all that implies is that an attacker needs to have a bunch of nodes and some mining power in order legitimise his transactions.

It's also a given (see the Satoshi quote) that txid's can change during a reorg. They are not - ever - meant to be relied on, as they are not canonical.

I'm recompiling it statically as we speak, the builds I put up yesterday were dynamically compiled (so you'd only be able to run them if you have Qt installed in exactly the same place I do). Should have those up within the next couple of hours at most (you have to first recompile the whole of Qt statically before you can build static binaries, lol).

The problem is that waiting leads to entrenchment. We've seen it time and time again; this very forum is an example of something that was haphazardly done to fill a need, and now we're lumped with it. If we're going to make a change that is trivial (this requires no effort other than renaming some stuff) but has far-reaching effects, then it is imperative that we do it now.

PayPal only use PayPal Wallet to describe their mobile app that you can also use for in-store payments, and this parlance has been followed by MasterCard with their PayPass Wallet, and the terribly unsuccessful Square Wallet that they recently killed off. When you go on to PayPal's website and sign up they give you the option of creating an individual account or a business account, so the term is in use and familiar to people. Perhaps it'll make more sense if I show you a mockup of the second step in the first-start wizard (please ignore grammar/spelling faux pas) -



Remember that we're not trying to do what Bitcoin already does. We're untethered and unhinged, and merely following in Bitcoin's footsteps has done Litecoin and others no good. In a sense (and I'm not trying to make comparisons here) we are in a position to do what Apple did when they released the first iPhone. Did touchscreen phones exist? Absolutely. Did smartphones exist? Most assuredly. Were there phones with capable browsers? Definitely. So what did the iPhone do differently that made it successful? It built on an existing foundation others had created, but it pulled everything together in a way that made it accessible to everyone. Windows Mobile in 2007 was for nerds, Blackberry was for businessmen. The iPhone was for everyone. Let's not constrict and restrict ourselves by looking at what Bitcoin does:)

MoneroChain is rebuilding their database, and it appears to be stalled, so the total coins in circulation you're pulling from them is broken. May I suggest you scrape it from http://chainradar.com/xmr/blocks (the Coins Emitted bit at the top right) as well as MoneroChain and pick the highest of the two?

lol - every node on the network? You understand that multi-sig is just an extension of pay-to-script-hash, right? When you understand P2SH we can talk.

Guys I must apologise. I thought we published last week's Missive after the Fireside Chat, but due to a bit of confusion it didn't get posted. So...today you get a double whammy, last week's Missive AND this week's Missive! You'll notice a special surprise in this week's missive (for Mac and Windows users...Linux users will have to wait an extra day:)

Thanks for quoting me:)

There was a lot of push-back in that thread, which surprised me as strasboug seemed quite logical in his thread denouncing Cloakcoin's PoSA as not being trustless. I couldn't understand how he could accurately describe Cloakcoin's system as not being trustless, and then think that a system that only requires 2 parties to collude is somehow "trustless".

Look, cryptography is VERY, VERY hard to get right. I've got a reasonable grasp of it and I would NOT attempt to invent new cryptography that didn't simply build on the foundations others have left. I notice a lot of hero worship in this part of the forum - "the dev said X" or "the dev promised Y" and everyone accepts that. Cryptographers (real ones) don't push out code until they've pushed out papers and completely opened their ideas up for discussion. More importantly, those cryptographers are also able to accept where they're wrong. There is NOTHING wrong with being flat out wrong about an idea...but when you stick with the idea in spite of it being bad, that's a dangerous road to drive.

Nothing is flawless, but this is YOUR MONEY. Expect and demand good and cryptographically sound solutions - fewer pictures, more maths in a "whitepaper"!

I heard you all agreed that the Bytecoin creators are aliens, and Satoshi is also an alien. Is it true?

Your transaction has been mined - if it's not been received on the other end they need to make sure they're synced up to the network and they have refreshed their wallet.

It was mined yesterday in block 174 516, you can check on any of the block explorers: http://chainradar.com/xmr/transaction/d031bf01b4529bfe90fce237b4dab4b5c09e26fd29e1fd48949efc7f028bc804

Your English is fine:) Let's take Proof of Stake out the picture, as PoS is flawed in many respects, and that is a discussion for another time. The rest of what you're saying is spot on, and it is both how Monero works and will work in the future. The higher your mixin level, the more signatures you mix with for your transaction. But then your transaction is also physically bigger (in terms of the kb size of your transaction). When we move to per-kb fees, this will mean that the higher your mixin, the higher the privacy (more ring signatures), and the more costly that transaction will be to you.

I don't understand this obsession with bloat. We've discussed this - at length. A linear improvement doesn't solve the underlying problem, it only delays its effect by a very short period of time. BBR's changes do not prune the blockchain, they provide a (relatively) meaningless linear reduction. It won't help mobile phones run BBR clients, so from our perspective it is a change that we are not willing to make. That does not deflect from BBR's change, I have the greatest respect for the work they've done, it is just that the change they've made is like me trying to use a cup as a bilge pump on a capsizing boat - it's not a solution to bloat on any level, and is not only ineffectual but may put users at risk (supposition, don't take this as anything more than a hunch).

There are two types of devices when it comes to cryptocurrency: those that can run a full node (20gb, 120gb, makes no difference), and those that can't (mobile phones, tablets). There is no middle ground. It's pointless catering to the "I'm happy with 20gb, but woah buddy, 120gb is crazy" crowd, because there are only 100 of them in the world and they're all on this forum:) So we're ignoring blockchain bloat as a non-issue for full nodes (as it is with Bitcoin) and we're addressing the matter of extremely-lightweight-clients in a completely different manner. That we choose not to use some half-measure as an intermediary should not be indicative of anything except that we don't do half measures;)

We will solve this, or it will be a non-issue, before the blockchain reaches 20gb.

I agree - this is a mountain of information to go through:)

OP, I'd like to thank you for confirming the suspicions many of us involved with Monero have held for quite some time. There are a handful of things I'd like to comment on.


I'm a moderator in the subreddit, and I can confirm that this happens on a daily basis. There are around 60 separate sock-puppet accounts we've found posting in the Monero subreddit. The creation dates are all between the 23rd of Jan and the 9th of Feb this year.


The core team consists of 7 people, and we hail from all over the world and are multi-faceted in our knowledge. This does mean we're sanity-checking each other, to be sure. Pretty much all of us have been around for well over a year, which I'm sure contributes as well. We try to keep our development as transparent as possible, and we publish all of our development efforts and links to dev branches on github in our weekly Dev Diary (part of the Monero Missives).

Thank you for the vote of confidence and for the effort you put in to uncovering this.

From an XMR perspective, not really. The multi-sig implementation is only at mixin 0, so we won't be merging that. We've also started diverging quite heavily from the reference implementation in our development branches, so chances are that there won't be anything we'll be touching there in the future.

Despite where this thread went, I would like to say that our relationship with Crypto_Zoidberg remains genial, and whilst there are some changes he's made that we don't fully agree with, there are are things he's done that we are interested in merging down (and vice versa, based on previous BBR commits). A couple of things require a bit of forethought and modelling on our side prior to implementation, but we don't have anything but respect for CZ.

No - we've discussed this on a number of occasions, and it's truly a non-issue until someone can prove to us that it is. The amount of hot air around this issue shows how poorly it's understood.

The first thing to remember is that all cryptocurrencies with "mixing" and other fluff in a bid for "anonymity" will end up with bloat. "But they can prune their blockchain!", I hear you say. Except that Bitcoin doesn't currently have the code in place to prune its blockchain or work off a pruned blockchain, and you can bet that some random altcoin developer doesn't have the technical chops to do this.

Consider, too, why this isn't "the biggest issue" for Bitcoin. Does Bitcoin's 20gb blockchain hamper adoption? No, because mostly everyone uses lightweight clients or web wallets.

The reality is that bandwidth and disk capacity is ever advancing, and there is little reason to think that Monero has a major issue if its blockchain ends up matching Bitcoin's and hits 110gb in 5 year's time. That having been said, there are definitely ways to trim on-disk usage, and we will look at doing this as time goes on. For the foreseeable future, though, this is a much lower priority than most things.

I don't really care about the back-and-forth you have with people that think XMR is awesome, that's your prerogative. But there are a few things you've stumbled over where you reply to aminorex (not a member of the core team) about stuff that the core team organises. So I felt it prudent to respond.


Regardless of how eccentric anyone is, the core team did not decide on these things for the sake of eccentricity.

The Monero Missive is meant to be a platform to provide an overview of the week, as well as as a way to announce things so that they don't get lost in the main ANN thread. I'm quite unsure as to how a little alliteration can give you the "heebie jeebies". If you're that sensitive I fear the Internet is the wrong playground for you.

Coupled with the Monero Missive is the weekly Dev Diary (oh dear, more alliteration, however will you cope). Whilst the content of the Missive is more easily digestible, the Dev Diary goes into greater technical detail for those efforts.

The #Monero-Dev Fireside Chats are irregular events aimed at, you guessed it, developers. Yes, we used the first one to show off the new GUI, but the bulk of it focused on developer-centric discussions of ongoing efforts. You are not really our target audience for that unless you're a contributor or you're building services around Monero, so feel free to completely disregard them.


I've spotted this mentioned too, and I can tell you that I honestly have no cooking clue what they're talking about. We don't play our cards that close to our chest, everything is pretty out there and in the open. Some of the stuff is mostly discussed on IRC and on github issues, sure, but our current work is no secret.

There are definitely other aspects of your post I don't disagree with, but I, for one, would appreciate you not leveraging criticism meant for the core team at someone else who is not responsible for the Missives or Fireside Chats.

Please don't advertise your pool in this thread, this is no longer allowed: https://bitcointalk.org/index.php?topic=718124.0

Bankrupt 5EVA because 5 is bigger than 4

I don't disagree with some of the things you've said, although we certainly have no control over whether people wish to express interest in Monero in whatever way they see fit. That having been said, I think the "out the gate" bit is a key element here. Monero launched on 2014/04/18.Even though BBR was announced a few days later, it only launched a full month after Monero, on 2014/05/17. I know that in the grand scheme of things this may seem inconsequential, but in the rapidly moving altcoin space it meant a full month's lead on BBR. Whether that is the only element of Monero's current success...I don't know...but it certainly played a huge role at the outset.

The Github repo is staging - dev doesn't get pushed to it until it's been tested, and even then the staging branch is not for production (that's what tagged releases are for). It would be absolutely insane to push commits straight into the staging branch, most especially because there ARE exchanges / miners / people who build straight off that branch, and if it contains bugs and falls apart we would lose credibility big time.

A month ago there were a handful of minor backports from Bytecoin, but there's nothing on the entire first page of commits that are anything but our work.

If you want to see the ongoing development, a good starting point is the Dev Diary in the weekly Monero Missives. A quick summary of the ongoing work would be:

• Abstraction of blockchain functions in preparation for moving the blockchain to an embedded database instead of all in RAM:
  https://github.com/tewinget/bitmonero/tree/bc2 (was: https://github.com/tewinget/bitmonero/tree/blockchain, moved to allow for refactoring)
• rpcwallet to replace simplewallet's rpc mode for all environments that use automation (exchanges, merchant systems, gambling sites, faucets etc.):
  https://github.com/tewinget/bitmonero/tree/rpcwallet
• unit tests for RPC functions:
  https://github.com/jakoblind/bitmonero/tree/rpc_wallet_test
• Proper backgrounding/forking for the daemon and rpcwallet (fork on *nix, service on Windows):
  https://github.com/mikezackles/bitmonero/tree/daemonize
• Move from VS2013 to mingw64 / msys2:
  https://github.com/mikezackles/bitmonero/tree/mingw and https://github.com/mikezackles/bitmonero/tree/rfree_mingw_test2
• Overhaul of CMakeLists to speed up build times and allow selective building of binaries and/or test suite:
  https://github.com/rfree2monero/bitmonero/tree/pr-20140808-rfree-cmake
• Replacement of all logging functions with OT logging system that allows for compartmentalisation of logs among other things:
  https://github.com/rfree2monero/bitmonero/tree/pr-20140808-rfree-otshellutils
• Complete overhaul of parts of the low-level networking code, adding QoS and bandwidth control to the daemon:
  https://github.com/rfree2monero/bitmonero/tree/dev-rfree
• New GUI developed from scratch -> wireframes -> mockups -> actual Qt interface. The interface is around a few weeks away from completion, then integration can start.
  http://imgur.com/a/ERheR