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

Maybe make the labels a little smaller or move them closer to the outside. The "D" at the beginning and end of decentralized is too close to the edge. The other two words look much better.

I left decentralized, private, digital

Try this

1. Exit simplewallet

2. Make sure your wallet.bin.keys file is securely backed up

3. Delete the wallet.bin file.

4. Exit daemon

5. Remove poolstate.bin file

6. Restart daemon

7. Restart simplewallet.

8. Wait for wallet to rescan (may take some time).

9. Check balance and resend coins

EDIT: Added steps 4-6

prompt, please, how to return coins?

^ this was my perception

The printed words do not work. Visually it is too cluttered, and in terms of meaning, it raises more questions than answers. Keep the icons only. Let people be intrigued by the design and ask questions. That is a good thing. It also removes the English bias.

This picture targets the Joe Blow demographic?
If so, the word "fiat" won't strike a chord.  The average American doesn't talk like that.  They think about cash, not "fiat." You don't need a word at all.  The greenback icon gets the idea across all by itself.
I would keep the icons for dollars, Bitcoin and gold, without the printed words, and print Monero under the M icon.
Otherwise, people will go what's that M doing there, then look at the other stuff, which they understand, and forget about the M.  
Monero is the thing you want to communicate, and it's the only word left out of a rather wordy picture.
In my opinion, the graphic might work better without any words at all, except Monero.  If you explain too much, people will tune you out.  You want to involve people and pique their curiosity.  Exposition comes after.  A T-shirt with a technical diagram may just make their eyes glaze.  It's transmitting information on a wavelength that us geeks understand perfectly, but it's not going to grab the average person.  The visuals should be enough to get them thinking.
Get them curious and then engage them on a personal level.

Someone should click together a T-Shirt shop with the above infographic, please.
At Spreadshirt, Shirtinator, RedBubble or wherever.


Every design & product should be available in two versions. 1.) No markup and 2.) a small markup, that will be donated to the core team, to be spend where they think it helps the proect the most.



I would buy some shirts, polos, T-Shirts and maybe one coffee-mug. :-)

The first reddit MAAM (Monero Ask Anything Monday) is on!

https://www.reddit.com/r/Monero/comments/43lob7/maam_1_monero_ask_anything_monday/

Hah! Didn't think you were gonna have to elaborate a statement in a dev meeting to a layman did you!

Thx for the clarification. Statements like that hang out there and if not expanded upon for the masses will always be interpreted in a less than forgiving light.

We know where it is relative to master; the context is that we need to establish what regressions we've introduced to 0MQ (if any).

So "state" refers to "regression state", "buildable state", and "releaseable state".

That makes sense except "on the state of the dev branch right now anyway", who has responsibility to maintains it and shouldn't the devs always be up to date on its state? How can you even have a meeting without this info? Or am I misreading this somehow?

RingCT integration task is not fully defined yet as the standalone crypto code was just recently completed.

Work on the dev branch was put suspended to focus on the 0.9 and 0.9.1 releases (and will remain so until the upcoming point release).

Why not?

For this that are interested, here are the logs from the dev meeting. Someone is working on an overview if you don't feel like reading the whole thing.

  who are we missing 
  tewinget / othe / warptangent / NoodleDoodle you guys around? 
  ^ 
  hokay 
  smooth? 
  smooth and luigi1111w are around 
  although luigi1111w is using some other nick 
  luigi1112 I think 
  4 
  mario1114 
  lol 
  about a year ago we did this using TeamSpeak 
  I mean Mumble 
  for you guys 
  which was nice, but it isn't as fluid as typing because sometimes you can't hear that someone else is talking 
  Firechat? Was cool 
  binaryFate: no we did a couple of actual dev meetings   
  but it's tough to sustain 
  Oh ok 
  I think typing is fine too. 
  This is fine 
  agreed 
  plus there are people working on Monero that would prefer not to have to use a voice changer just to participate :-P 
  ok so there are a few things on the agenda   
  I'm sick so my voice is already changed 
  the format seems to have been working well for kovri too 
  the first thing I think we should discuss is the dev branch   
  we've fallen back into the habit of merging stuff to master 
  That's because bugs 
  I know 
  we're going to have to do a point release to fix the v1/v2 / stuck transactions bugs 
  are there any bug fixes waiting in the wings, or should we do that next week? 
  That last commit thing, which I'll have to think about a bit more. 
  Also, possibly merging the per-tx bits in lmdb. 
  which? 
  tx_{unlocks,heights,outputs} 
  ah 
  And output_{keys,amounts,indices,txs} 
  DB format change, I don't think that's a bug-fix 
  Way more of htose than blocks 
  maybe we need to consider a more generalised approach to format changes   
  something like Laravel's migrations 
  it'll have to be per-DB-format anyway   
  per-DB-type I mean 
  i've got schema changes i've been using for a couple months, for better use on hdd, but they aren't bug fixes. 
  two sets of bug fixes not yet added though 
  ok if they're not considered crucial for 0.9.x then we can put them into dev? 
  warptangent: since I've been working on the same thing, I guess I should take a look at your stuff 
  1. berkeleydb support for importer - almost ready, some argument usage cleanup 
  Once I re-merged then 
  but I don't consider anything I'm looking at now as bug-fix 
  (this is how we meeting https://i.imgur.com/OR5ZVoI.jpg) 
  2. finish hf fix for importer - mostly done, pending some cleanup with bdb 
  hokay 
  (I have a wineglass here too, sadly empty) 
  hyc: yes, that would be good. i think i mentioned the tx changes last month to avoid as many subdbs with tx hash keys 
  also I think the thing that's holding up a general move of effort to dev is that we haven't bundled CZMQ / 0MQ in source, which makes compiling a bit painful 
  any objections to the bundling? 
  how much of a pain is it to change formats? 
  I haven't even looked at dev. no objection from me 
  luigi1111w: mostly just requires copying data to a new table and nuking the old one 
  Hmm. I have a few patches to czmq, to make things build. 
  Not super sure whether it was me being dumb or not though. 
  ok well moneromooo, maybe post-bugfix do you want to do the merge from master to dev, and then plonk those patches on? 
  I'll get it in the source tree the meantime, and cmake-ify all of the things 
  I'll merge yes. Then you can add zmq to the cmake stuff Then I'll add my patches if they're still needed. 
  Great, ty 
  great minds think alike 
  ok next I'd like us to chat about a style guide 
  we've been working on one in Kovri that we can possibly use for Monero 
  https://github.com/monero-project/kovri/blob/master/CONTRIBUTING.md#style 
  oh, I do have one outstanding - tweak to BlocchainLMDB::get_estimated_batch_size - change batch_safety_factor to get blockchain_import to succeed on 32bit 
  not necessary to read the style guide now, just more a general sense of if everyone is comfy with a style guide, and if anyone has any particular preferences   
  i have no objection to any reasonable style guide but i do object to re-styling of existing code 
  Pages and pages of stuff ? :| 
  I object too, if it's only restyling for the sake of it. 
  ok so more of a restyle-as-you-go   
  That massive reindent patch already caused me grief 
  which is in line with our refactor-as-you-go approach 
  Apply the style guide to new code 
  imo the best policy is keep the style on small chages to existing code and new style on new code 
  there is probably a gray area there 
  should we assume from this point on the code is indented like the majority of the code so far - 2 spaces, not tabs, not 4 spaces. 
  agreed 
  warptangent: that's the one area where we differ from Kovri, I'd lean towards yes 
  I tend to keep the style of whatever I'm hacking on. And I doubt I'll read all that google style guide thing. I'd prefer we use common sense. 
  moneromooo: style on the current project though, not different styles per file, right? 
  Whatever code I'm modifying. 
  It causes the least problems. 
  moneromooo: don't worry about the Google style guide, the 16 points we've put in for Kovri are more what I was referring to 
  the majority of files are one style in the codebase, with a few that became some kind of hybrid at one point 
  Oh OK. 
  With that out of the way... 
  ok - everyone happy with that as a general starting point? I can dump those points in and then we can take pull requests on it if anyone wants to refine / change things 
  yes, seems good 
  I would push harder on "code should go in a .cpp not .h" 
  hyc: agreed 
  I'll make it clearer 
  moneromooo: did you want to raise a point, or were you saying we can move on? 
  overall it looks sane to me 
  I'm good. 
  ok   
  next point is also administrative in nature 
  we'd like to adopt the Collective Code Construction Contract that 0MQ uses, as a guide for project administrators and for contributors 
  http://rfc.zeromq.org/spec:22 
  we can discuss it more in future, but the long and the short of it 
  is that we merge every PR as long as it doesn't break the build 
  if it does something bad / dangerous we can have a follow up PR to revert 
  but the aim is to avoid PR-hell where everyone comments on a PR for days and weeks and it never gets merged 
  because it's never "perfect" 
  so merge, create issues on Github where something is lacking (eg. new feature, little or no tests - create issues for tests) 
  This PR-hell problem's never happened, has it ? 
  moneromooo: not in Monero yet, but Bitcoin is chock-full of it 
  ^ this is for dev branch, right? 
  I think common sense is again a better thing than going the opposite extreme. 
  gingeropolous: this is in general 
  i haven't read the zeromq document thoroughly, but does it leave room for the common sense aspect? 
  moneromooo: the problem is that there are lots of nuanced situations where "common sense" isn't that common :-P 
  i dont think there should be an arbitrary merge policy on master, but it is already stated by me that i dont think anything but tagged releases should go on master 
  Well, if it's nuanced, fine. 
  warptangent: it does, yes 
  as explained by Pieter to binaryFate and I last year 
  if the concept of only taggest releases on master is no adopted then i would oppose going even further in the other direction 
  *tagged 
  smooth: yes that's a given 
  master represents a stable, tagged release 
  we work in dev 
  anyone that submits a PR to master gets it closed and asked to submit it to dev 
  anyway what I wanted to say, is that Pieter explained that the reason that you want to merge-all-of-the-things and then revert something bad is that you have a historical record of the bad actor   
  there needs to be a place for bug fix releases though 
  I'm with you fluffypony. 0MQ founder/leader feedback on this approach was extremely valuable. 
  There's also the potential thing about not being able to use the 0mq version in time for the next 6-month fork. It wasn't exactly usable yet last I hacked on it. 
  Common sense might work now, long term with a higher market cap we'll face same issues as btc 
  Where common sense diverges and the code Base ossifies 
  As a non programmer smooths comment seems like the safer approach. Thank you for clarifying the master vs dev branch issue fluffy. http://rfc.zeromq.org/spec:22 sounded scary as applied to PRs sent to master before dev 
  smooth: it doesn't preclude it 
  moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine 
  What's the envisionned time scale for ringct? 
  the idea of a historical record is good 
  we have similar issues with OpenLDAP - you need 3 branches 
  one for dev, one for released code, and one for release bugfixes 
  but i would make the case then that 0MQ should be reverted since it is unusable 
  particularly when dev and release are far apart 
  im not actually proposing this because i know it would be a mess, but making a point for the future 
  like now, where dev has 0MQ and release doesn't 
  smooth: I agree - moneromooo and I will play around with it next week and make a decision   
  Reverting isn't really possible. 
  moneromooo: we could drop dev and re-branch 
  But one could add ringCT to a new branch based on master. 
  if it came to that, I mean 
  That'd be a lot of pain. I'd rather not. Much better to hack on master and merge do dev again. 
  ok 
  imo something like zeromq should be developed on a separate branch somewhere, until it is actually usable 
  s/on master/on a branch based off master/ 
  smooth: it was usable-ish, we might have regressed some in fiddling   
  Yes, that. 
  anyway - let's evaluate and figure out 
  I think I added all missing RPC so it cn be used, just not by people who want it to work without problem. 
  ** moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine <= I welcome this. Just wanted to say that imho it's important to have RingCT active in the september/october hard fork. Carry on. i'm watching 
  doing all new work in dev is fine, but backporting bugfixes to release will become non-trivial as more features are added to dev 
  hyc: I guess it depends on the importance of a bug fix 
  It looks to me like ring CT is going to need a lot of changes to bitmonerod/CN. September looks very close. 
  we'll see   
  I don't think we need to create a pressure-cooker for it 
  ok can I go on? 
  There are trade offs here. I see problems if dev and master deviate materially 
  it seems like 3 branches as smooth mentioned would be easiest for everyone in long run even if it requires more effort now. 1.dev 3. release and bug fixes 
  xmrpromotions: otoh we can backport fixes straight into master to allow for immediate testing by affected parties 
  With bug fixes as a transition from dev to master 
  again depends on the nature of the bugfix   
  like warptangent's work on BDB and the importer probably aren't critical enough to go into master 
  the importer works properly when it has the hard fork support though, and that uses the bdb support 
  If someone wants to rewrite that hard fork code, btw, you're welcome. I don't like it, and I'm not sure how to improve it. 
  My concern is master deviating materially from a quasi stable dev 
  ArticMine: something like ringct would have to be done in both master and dev 
  So a project based on master would need a major rewrite after a tagged release 
  we did dual-PRs for a while 
  we can do them again 
  might be easier than The Grand Merge 
  something like ringct should only be in dev imo 
  Yes anything fundamental has to be done in parallel 
  until it gets released of course 
  I think let's defer further discussion of this till the next meeting 
  agreed to both 
  we don't have enough info on the ringct effort or on the state of the dev branch right now anyway 
  One thing I miss in discussion is what is master purpose? Do we want to encourage users to compile from it? How is master gonna diverge from tag release between them? 
  I agree and lets carefully review the zeromq rfc in the meantime 
  I think large things should go to their own branch (ie, ringct). Smaller things can share branches (to dev). Both end up being merged to master when ready. 
  binaryFate: no matter what we say people clone and build master 
  **<- this guy 
  it doesn't matter how much we encourage building a tagged release 
  so we made a decision ages ago that master would be stable 
  so that anyone pulling and building master doesn't get some hacky, broken branch 
  Ok 
  moneromooo: I don't know if we want topic branches in the main repo, but perhaps a more generalised "staging" branch, as long as anything going to that is also PRd to dev 
  It can be in any repo. 
  i think not in the main repo is fine 
  Like I was hacking on tewinget's branch for a while. 
  yeah that's a good point 
  +1 
  as long as that person is around and accepting PRs it's perfect 
  then one big PR to dev when it's ready? 
  If we go to a dev/master setup, how does dev get merged to master anyway ? 
  that has worked before, yes 
  yeah, keep main repo relatively clean 
  a new feature can get a sort of "lead dev" 
  moneromooo: when we release we merge from dev to master and tag master 
  and contributers can hack on his repo 
  So master becomes a copy of dev at that point ? 
  yes 
  Yes but a six month cycle could be too long 
  thats a different issue 
  how often to have major releases 
  we can do major releases whenever, as long as we have major fork releases every 6 months 
  also are releases time based or feature based 
  kinda both ? 
  yeah both 
  feature-based is all that makes sense to me 
  The merge to master may need to be more frequent than major fork releases 
  feature based, but the rolling hard fork also pulls time based I think. 
  yes 
  Those Dev -> Master merges would happen with what kind of tagging? Point fix? Even more frequent? 
  binaryFate: depends on how stable dev is 
  so new features thus shouldn't be in dev until they are working properly/ready for release 
  because of timed releases 
  time based means that if you have 6 features in progress and one doesn't work in time, you do the release anyway, without the unfinished feture 
  smooth, luigi1111: yes, you're both right 
  it works as long as the half finished feature isn't partially merged 
  or whatever 
  the only reason 0MQ got pushed to dev anyway was because oranjuice could no longer work on it, and it was basically done 
  but I think let's make it the last time that happens 
  then we avoid complication 
  ok 
  tbh I'd be tempted to not really care about people building master. If it's said clearly to use a release if you don't know what you're doing, then it's your problem. 
  i agree with ArticMine that we can have releases sooner than 6 months 
  ah ok. so how the 0MQ happened is not how it will be in future 
  Agree with moneromooo 
  ok guys we're running overtime, so let's drop this for now, we can pick it up again later 
  i think it is simply unnecessary to merge to master 
  er sorry, commit unreleased stuff to master 
  I think one of the problems with 0mq is that oranjuice kinda left 
  any developer can handle getting the latest stuff from someone ele 
  *somewhere else 
  So it jsut had to be merged 
  Let get back to this question at the next meeting 
  ok 
  last two things   
  yup 
  the first is that we have some major efforts coming up, besides ringCT, and things like epee, the 3 (THREE!!!) different logging systems, and a bunch of unused stuff is going to get in the way 
  I'd like us to decide whether we want to keep hacking around things 
  Does epee really get in the way ? 
  or if we want to spend the effort now dumping this stuff for things that are easier 
  it makes 32bit builds murder. but if we can abandon 32bit, that problem disappears too 
  epee does ? 
  yeah 
  moneromooo: yes it does; it made QoS an absolute nightmare to do 
  and it's still not done properly 
  We'd have a replace a lot of stuff. 
  32bit especially on windows is going to be around for a long time 
  + TAILS 
  And a lot of somewhat low level stuff. 
  the multiple logging systems situation is strange, but i don't think it's interfered with current work. is there any knowledge on rfree's likelihood of returning? 
  warptangent: low to impossible at the moment 
  I mean, we can rip and replace the logging stuff with boost::log 
  all the console stuff can go ncurses or similar   
  id be more in favor of specific items like that, done on feature branch 
  and the wire protocol can go ZMTP, since we have a 0MQ dep anyway 
  eventually we'll get to a point where we're no longer reliant on epee 
  I agree with the bit by bit approach. 
  that sounds manageable 
  also then we'll actually have usable Doxygen docs 
  the thing to bear in mind is this has virtually zero end user benefit, if not actually zero 
  yes 
  on the flip side, we can plug the GUI in via 0MQ instead of monero-as-a-library 
  Well, the benefit is said to be for 32 bit users. 
  so we have a shortcut of sorts there 
  (in terms of users clamouring for stuff) 
  moneromooo: and long-term viability   
  we've had potential contributors ask for an architectural doc for the code, and get turned off when there isn't one 
  so there's scope to slowly bring the codebase in line 
  i dont believe there is anything about the current code that precludes a GUI. After all, BBR has one with basically the same code. 
  huh.. contributors that are turned off so easily ... I wouldn't expect much use out of them if they stayed 
  I was kinda thinking that too... 
  I guess, but tbh it does make the project seem significantly less mature 
  which I guess is fair, it's not even 2 years old 
  less hurdles, more good 
  it is somewhat hard to come up to speed with the code, i would agree with that 
  alright 
  last thing so we can wrap up 
  I just wanted to deeply thank everyone who has contributed and who continues to contribute to Monero development, whether it is Monero's core, the website, any other peripheral projects 
  both on behalf of the core team, and on behalf of the community   
  you all do an amazing job, and we've done a truckload of work in 2014 and 2015 
  so here's to an amazing 2016 
  hear hear! thank you fluffypony for herding the cats so good 
  hear hear! 
  thank you! 
  Thanks for all the good work 
  thus concludes the first meeting, next one in two weeks 
  thanks fluffypony 
  thanks 
  Thanks to you fluffy (enjoy that wine)! Thanks to all of you, awesome community. 
  Thanks fluffypony! 
  ** thanks all 
  is there a buffet? 
  Infinite_Jest: snacks will be served in The Grand Ballroom in 15 mins 
  ok great but seriously thanks! 
  thanks fluffy

Ah, I'm stupid - I have no rank to wear an avatar yet.

Resized to small size it's quite readable.

Here you go, not sure if link will work for you or not.

https://bitcointalk.org/index.php?action=avatar;u=467300

yeah i thought it would be difficult/impossible; but also that maybe there's a way to issue share/pay dividends based on monero's crypto; so without copying xcp but finding a monero way to do that. (i'd be really interested using such feature for a side project lol)

^^^^^

nice! I think he meant to reduce it to a stylized version, so essentially the same as the above, but no text labels in the circles whatsoever.

It sort of invites people to wonder ... "what is Monero, if it is cash, bitcoin, and gold? I know how ven diagrams work, so this is saying that bitcoin isn't cash or gold? hrmmm...."

Now I know the author of the idea. As I stated on Trello I found the draft of this and decided to make infographic of it. I saved picture from somewhere and did not remember author.

Here you are, the version for avatar



BTW, how do I make an avatar on this forum?

If you look here it is only kind of mentioned as a side-chain at the very bottom:
https://getmonero.org/design-goals/

I'm not sure how difficult/impossible it would be to implement something like XCP directly on the main XMR chain.