Agree about splitting.
Agree about list_transactions. Actually everyone who want to see some API could open a ticket on github/or write me pm and specify what api he wan't to have - i'll implement any reasonable API that is needed. It's absolutely not a problem.

PS: read your article on Mike's Data... impressive

Thanks!

Does memory leak appeared after new scratchpad api  was added?

Good news!

We have new build (v0.2.0.33(63f5db0)) with security fix, so i recommend to update it for everyone who cares about privacy.

http://boolberry.com/downloads.html

Details: Mixins could be partially or complete useless.
When you creating transaction with mixins you expect to have some unliknability degree for your transfer. But if you mixing with outputs that already spent - this won't make your transfer actually unlinkable. Original algo didn't track if transaction's output are spent or not, and when wallet was requesting outputs for mixins via API COMMAND_RPC_GET_RANDOM_OUTPUTS_FOR_AMOUNTS it was returning any outputs, including those that have been spent.
Now, starting from this build, implemented tracking for each outputs - if it was spent or not, and COMMAND_RPC_GET_RANDOM_OUTPUTS_FOR_AMOUNTS returns only unspent outputs for mixins.

Update strongly recommend for eveyone who like use mixins!


PS: Also minor changes added upon the requests:
* added to windows download section .zip archive with all files (in addition to the installer).
* added root directory "boolberry" in linux archive

No problem, and actually i had no idea what to do with that problem, so thanks god this was selfsolved

So the problem is solved ?

Yeah, and i also see A LOT OF tries to open wallet with wrong password.... well, i'm sleepy now, i'll see into logs again tomorrow, can't promise that i will help you, especcially if password is really broken - but i'll try.

If you have GUI then find "qt-boolb.log" file in application folder (usualy "C:\Program Files\Boolberry\qt-boolb.exe" for windows)

Send it to my email: crypto.zoidberg@gmail.com
What version are you using ? Windows/linux ? What build ? GUI or CLI ?

Hi John!
That is really strange. Does it possible that you use wrong wallet file ? or wallet from different altcoin (monero/bcn/xxx-cn-dumb-fork) ?
Another guess - if you have you password wrote on the paper, may be you miss register or '0' -> 'o'.
Anyway, it's a first time i see such issue. So if your password is really correct, you probably have damaged keys file.
Would you like to send me a log file from your wallet/GUI ?

Hey! SlyWax! Nice to see you! How you doing ?!

btw: cryptofolio.info wrote wrong algo, we not cryptonight, we wildkeccak

No problem, but can you give a little hint why you want to use it in that way on windows ?

Yeah, it may work until project is small, with mostly controlled community.

Sorry but its just naive to think that you could communicate with users and services in world famous product. It's mostly not possible to convince people to update their software even if you have product users subscribed emails or followers or whatever. They just lazy or don't care. Not to mention cryptocurrencies, where you have no idea who are using your coin.

Imagine what would happen if significant part of network won't update it(by different reasons) at time of block X ?
 

I'm not decides which, all RS will be cut-off after reaching some level of deepness. And this won't hurt anonimity or mixins. Or, if you think different, could you mention concrete technical objection ?

Here you contradict with yourself - if you do hardfork in the way you mentioned(just hardforked from block X) you not giving a way for users to decide.
I mean if some of them really decide against - then you just fuckup hardfork with network split at the moment of block X.

This why bitcoin have careful protocol for hardforking, where you have to wait until network will update to needed version and really give users a way to decide.


I didn't say that hardfork is not an option at all.
The flame started from my words:
and I am deeply convinced of this.
So my point is that hardfork is risky and/or slow case, this should be used only in extra situations, where you have no other way to fix issue.
And i do not rule that we in BBR would be forced to make hardfork once a day. And probably more than once, i agree that nobody can foresee everything in advance.

fluffypony, it is no doubt that you simply hypocrite. You sometimes pretend to be friendly and nice to bbr, but don't lose any chance to spread sensless FUD against BBR and me.
So keep you word and stop "that largely irrelevant debate".

Well, thanks
you are not giving me any chances to post something wrong 

I understand what you mean, it's extremly important to be able to fix issues even if it need's hardfork. And this is exactly why i implemented alerts - that make users aware of critical updates asap.

But i still very disagree with you "disagreement".
Hard fork is very painful especcialy for big network - painful and slow process, since you need to wait until about 95% of network gonna update sortware. And unfortunately you don't have any reasonable way to force them to do that.
And i talk now about the case when everything is okay with community. The worse case will be if some part of comunity(or some silent miners) will disagree with hardfork changes and they would try to ingnore that - this may do hardfork impossible at all.

I have now doubt that you aware of how difficult it would be to make a hardfork for bitcoin now(if they want), and how much time it will take.

I meant it would be perfect for developers to be able make hardforks easily when they want - but it has some contradictions with crypto-currency nature (in my vision): it's a basement as a set of known rules and technologies. And when you change a basement it's very risky to ruin the whole construction.

So my point that hardfork is a bad case for currency, especcialy for widespread currency.

smooth, i'm sorry that i said it in that rude form, just f@#king tired of XMR supporters who "just misunderstood on this point" - it is not the first time, and not second.

And if you knew that kbm was wrong there why you didn't correct him ? 

Hi kbm.

It's important. Anonymous transactions with a lot of mixins or transactions that send big amounts have a very big size, and 90% of such tx size - is ring signatures.
So it's important to save blockchain size if it possible, and FYI -it's was just a few lines to implement this.

a) We have more real GUI than you guys, it's just a fact.
b) Architectural changes that will require hardfork better to implement before launch, so i implemented those features that i supposed to be important fixes of CN and can't be fixed in future without hardforks. You prefer to build community instead of it and later torment network with hardforks ? ... well, Monero obviously had no choice since it was launched by TFT, and i could understand it. But trying to convince people now that it is normal practice sounds senseless.

a) It's legitimate in BBR, and it is illegitimate in XMR. Feel the difference.
b) It's obviously that db is not critical for next few months. Atm end-user won't feel any difference - in BBR we have about 1-2 seconds for loading blockchain from storage file. So now better to focus on really critical issues.

kbm, you either lie or just don't understand technical details: pruning ring signatures do not affect any mixin's or anonymity, this make help you to understand why (if really you want):




Skipped other part of post since there nothing to discuss.


UPDATE: About whitepaper - all Monero's activists comments was focused on everything except main - conception of blockchain based PoW. And even after  dga's post with concrete comparsion - it was ignored by Moneros - that is the best prove that this is well done.

Nop, you can't, i've explained my vision in my prev post.
In block you could register one alias, OR update alias with associating it with different address and comments, to do that you need to prove that you own this alias by signing update message with wallet's secret key. Last feature implemented in core and in unit tests, but not represented in command line yet.

I see aliased mostly as an option for business in future(like a visit card or for colored coins) and a personal aliases for early adepts or persons who able just to buy it.
When i was thinking about different ways to implement aliases i also considered pratical issue about aliases database size - if i let alias registration very easy - in special transaction for example - than aliases database could be flooded with thousands of senseless aliases, and user would be forced to keep that crap on their computers. So we need predictable amount of possible aliases -> easiest way to tie this with blocks.

So i've decided to have only one alias per block, we have 720 blocks per day - it's 263 520 aliases per year, seems to be a enough and reasonable.