Monero XMR ... Why do people fall for the shills and bullshit?

[smooth]

I've seen the QT creator screenshots. Can't touch it though.  Where could I find the link to try it out in the flesh.

The links are here: https://bitcointalk.org/index.php?topic=583449.msg8388993#msg8388993

I think you will likely have the same issue with boost libraries though. Static binaries are still a work in progress but if you install boost the above should work.

[1714738122]

1714738122

[1714738122]

1714738122

[btc-mike]

You can compress a file into an archive. You haven't made the file smaller, you've just compressed it. Putting blockchain into a database hasn't trimmed the actual dataset.  It's just put it into a database, BBR would actually reduce the size of the dataset. Spending time on database is a commendable piece of work and a needed contribution to cryptonote, yet If I'm not wrong it's something which can, and would be expected be adopted by others. So you can have a 'pruned' dataset IN an embedded DB.

But it's not pruned, it's 'pruned'. It will continue growing forever - just because he bought an extra year or two for something that's not even really a problem for easily over five years doesn't really sell me on it right now. Specifically because it's an impartial solution to something that's not important right now when the chain is small. If he doesn't spend time on things that are important right now - building community, a real GUI, protocol bug fixes, multisig, firing btc-mike .. and instead spends all day working on things that have zero effect right now .. but can be done in the future .. then why would I ever think that he's gonna be working on the right thing? If one were to take this illegitimate 'pruning' as a selling point .. I would feel that there's a distinct lack of prioritization. I'm just not sold on that one, because of the trade offs involved (below). He has time to create a database - so why not work on that? Yes, I agree that 'pruned' in an embedded DB would be fantastic, but the reality is that taking a potshot on my mixins isn't the way to 'prune' cryptonote. I don't know what is .. but it's not that.

It was easiest to add sig pruning before launch. BBR can add a database later, when it is needed.

Care to elaborate, exactly how he ruined your anonymity set? factoring in the mandatory mixin features added. I don't disagree with some of gmaxwells statements though.

That's just it - now there's mandatory mixin features, you're left with no freedom to choose to mix at all .. and you pay higher tx fees because of that. What does this spur? Someone on the CN site said it best: A tragedy of the commons! It will get to a point where the biggest damn transactions will be chosen over the small ones, to an extreme and much faster when on a comparison with bitcoin or even Monero. The transactions are already larger with CN - there's only so many that can fit into a block, and even then there's only so much to the adaptive limit. The space will run out, and miners will cash the transactions worth the most value. It will cause transaction witholding attacks etc etc .. not something I'd want to encourage. Apart from that .. CZ decided to make space by trimming RS's. That means this data is not there to mix with when it originally would have been! Now we absolutely need miners to cash the highest mixin transactions in order to make more of an anonymity set, so that you can remain cryptographically anonymous in the first place!

There is not a mandatory mixin feature. Tx fee is not variable.

.. white paper ..

Yes, they get torn to shreds. Unfortunately we made a mistake, but we took the feedback and corrected the error.

[rpietila]

half of all supply mined within a year.. seriously?

It is 39.4%. Compares favorably to to the bulk of the alts, though.

Questions for you: 1) Do you consider the emission curve of XMR to be preferable to the one chosen by BBR 2) do you consider the 60s block time to be optimal, or would you preferred it to have been changed?

I think that neither the emission curve nor the block time is optimal (my expertise is much better in the emission curve though). The Monero devs inherited them from TFT, and changing them now would require a near-unanimous support from the community.

I think rpietila has posted the most exact emissions charts. I tried to link them but couldn't find it. Perhaps he can help.

Here

[Anotheranonlol]

It is 39.4%. Compares favorably to to the bulk of the alts, though.

From your chart,

Code:

22.08.2015	 9,065,185 	 12,901 	0.14%	8.959028

isn't that ~49.1% (From your numbers) or am I missing something?

I think that neither the emission curve nor the block time is optimal (my expertise is much better in the emission curve though). The Monero devs inherited them from TFT, and changing them now would require a near-unanimous support from the community.

True. Can't see it happening. It's relatively early in the came but would upset the apple-cart. Better follow the the LTC approach and just stick with what we've got, wart's 'n all. The classic 'silver to btc's gold' as well as 'asic resistant' lines can be re-used, plus a few new ones. Once the emission dies down a little things should calm a bit at least. Hopefully some cash will go out of the old and into the new.

[ArticMine]

The correct date for one year from start of emission should be 17.04.2015 not 22.08.2015

Code:

17.04.2015	 7,276,274 	 15,361 	0.21%	10.667361

[Anotheranonlol]

The correct date for one year from start of emission should be 17.04.2015 not 22.08.2015

Code:

17.04.2015	 7,276,274 	 15,361 	0.21%	10.667361

half of all supply mined within a year.. seriously?

to clarify: it's ~49.1% if you interpret my comment as referring to within a year from the date I posted the comment, or ~39.4% you posted if you interpret it as referring retrospectively to the start of the emission from the time it was launched by another developer under a different name, not in it's current incarnation (taken over and rebranded as MRO/XMR by a new group. )

[fluffypony]

I've seen the QT creator screenshots. Can't touch it though.  Where could I find the link to try it out in the flesh.

You're on OS X, right? Here you go: http://monero.cc/downloads/guipreview/mac/monero.zip

Per the Monero Missive from last week when the binary was released:

"We know everyone is quite keen to play around with the GUI. We are still doing a great deal of underlying work, but we wanted to get the interface out there for everyone to have a play and see how they like it. There are some bugs (for example, resizing the MiniWindow interface does not work), and there are some spelling errors that we'll fix as we pull everything out for Qt Linguist to handle translation. But if you're happy to play around then please grab a binary - we'll take feedback in the form of github issues as soon as we've finalised the initial release of the interface and have it up there. "

[kbm]

There is not a mandatory mixin feature. Tx fee is not variable.

Your own presentation, page 9 and after talks about nothing but forced mixins:

http://www.slideshare.net/boolberry/boolberry-solves-cryptonoteflaws-37055246

Also, your developer has said you are wrong here also:

It does, because it:

...FORCES other people to use some specific level of mixin factor in future transactions....

And this is precisely showed in our presentation.

Also, this is discussed here: https://forum.cryptonote.org/viewtopic.php?f=12&t=239


Additionally .. are you joking or serious that the tx fee is not variable with the size of the transaction? Not much of an abuse deterrence here, now that you're entirely dependent on forced mixins to provide 'guaranteed' anonymity.

[crypto_zoidberg]

Hi kbm.

But it's not pruned, it's 'pruned'. It will continue growing forever - just because he bought an extra year or two for something that's not even really a problem for easily over five years doesn't really sell me on it right now. Specifically because it's an partial solution to something that's not important right now when the chain is small.

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.

If he doesn't spend time on things that are important right now - building community, a real GUI, protocol bug fixes, multisig, firing btc-mike .. and instead spends all day working on things that have zero effect right now .. but can be done in the future .. then why would I ever think that he's gonna be working on the right thing?  

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.

If one were to take this illegitimate 'pruning' as a selling point .. I would feel that there's a distinct lack of prioritization. I'm just not sold on that one, because of the trade offs involved (below). He has time to create a database - so why not work on that? Yes, I agree that 'pruned' in an embedded DB would be fantastic, but the reality is that taking a potshot on my mixins isn't the way to 'prune' cryptonote. I don't know what is .. but it's not that.

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.

....Apart from that .. CZ decided to make space by trimming RS's. That means this data is not there to mix with when it originally would have been! Now we absolutely need miners to cash the highest mixin transactions in order to make more of an anonymity set, so that you can remain cryptographically anonymous in the first place!

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.

[smooth]

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):

Kbm really isn't a lying kind of guy. He's an XMR supporter yes but not a mindless shill or troll. I'm sure he just misunderstood on this point, and if he has questions about I would be happy to help him understand. Zoidberg is correct on this point.

[crypto_zoidberg]

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):

Kbm really isn't a lying kind of guy. He's an XMR supporter yes but not a mindless shill or troll. I'm sure he just misunderstood on this point, and if he has questions about I would be happy to help him understand. Zoidberg is correct on this point.

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 ? 

[smooth]

b) Architectural changes that will require hardfork better to implement before launch

I largely disagree on this point, and I think it is fairly important.

It is better to be able to manage hard forks effectively with thoughtful design, good communication, broad buy-in, and successful execution (many of which ultimately reinforce the others). If hard forks become a "torment" (or worse are viewed as something that can't be done at all) this is a symptom of a much more serious problem with the development process and community that points toward paralysis, stagnation, and, likely, death.

Not that there was anything wrong with launching a CryptoNote fork with a different blockchain design from the start though (separate question).

There is a likely point of extreme stability, maturity, and near maximum adoption where further hard forks become both impractical and unnecessary. But as long as coin is young and in active development you had better plan for hard forks or you can't adapt and will likely be left behind. No one can make every important decision in advance.

This is theoretical though, as Monero hasn't delivered any hard forks yet. So we will see. If we fail to pull them off I think we will be in trouble.

[smooth]

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

Because he writes long posts and has a bad habit of not breaking up paragraphs, which I find makes them extremely hard to read, so I usually don't. I don't know if he is a native English speaker or not, but either way I find your writing easier to follow than his.

[fluffypony]

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.

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.

Your attitude is appalling and quite shocking, crypto_zoidberg, especially given that I spoke so highly of you just a few posts back in this thread. I am so disappointed in you - I genuinely and truly believed you were more of a man than this. I thought I had read your character well and found you to be honourable, but now I see I was gravely mistaken.

I will not speak to your individual points since I have no desire to continue to engage and re-engage over a debate that is largely irrelevant. I do believe that both Monero and Boolberry have something to offer the community at large. I have, however, lost all respect for you and for Boolberry this evening, and I am saddened by this turn of events and the dishonourable behaviour I have observed.

Oh and as for responding to dga - if arguing over "the best" PoW algorithm was worth more than 20 seconds of my valuable time I would have responded. I respect dga very much, but I do not see a need for endless and ongoing PoW comparisons. We are not bound to CryptoNight by blood, and if we change in future you can bet it will be to something superior like a future iteration of Cuckoo Cycle and not to something functionally indistinguishable like "Wild Keccak". Rehashing that argument over and over is pointless.

[smooth]

Additionally .. are you joking or serious that the tx fee is not variable with the size of the transaction?

In the original cryptonote code it is not. However, ultimately miners will prioritize smaller and simpler transactions with the same fee so if you want a large transaction to confirm quickly (if at all), you probably need to put a bigger fee on it in practice.

[crypto_zoidberg]

b) Architectural changes that will require hardfork better to implement before launch

I largely disagree on this point, and I think it is fairly important.

It is better to be able to manage hard forks effectively with thoughtful design, good communication, broad buy-in, and successful execution (many of which ultimately reinforce the others). If hard forks become a "torment" (or worse are viewed as something that can't be done at all) this is a symptom of a much more serious problem with the development process and community that indicate paralysis, stagnation, and, likely, death.

Not that there was anything wrong with launching a CryptoNote fork with a different blockchain design from the start though (separate question).

There is a likely point of extreme stability, maturity, and near maximum adoption where further hard forks become both impractical and unnecessary. But as long as coin is young and in active development you had better plan for hard forks or you can't adapt and will likely be left behind. No one can make every important decision in advance.

This is theoretical though, as Monero hasn't delivered any hard forks yet. So we will see. If we fail to pull them off I think we will be in trouble.

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]

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

I argue that none of them are widespread, nor even particularly close. If Bitcoin has problems with this issue, well, see my previous post for my opinion on that. It applies to Bitcoin as much as it applies to any other coin. Their example is not one to follow.

[crypto_zoidberg]

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

Because he writes long posts and has a bad habit of not breaking up paragraphs, which I find makes them extremely hard to read, so I usually don't. I don't know if he is a native English speaker or not, but either way I find your writing easier to follow than his.

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

[crypto_zoidberg]

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.

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.

Your attitude is appalling and quite shocking, crypto_zoidberg, especially given that I spoke so highly of you just a few posts back in this thread. I am so disappointed in you - I genuinely and truly believed you were more of a man than this. I thought I had read your character well and found you to be honourable, but now I see I was gravely mistaken.

I will not speak to your individual points since I have no desire to continue to engage and re-engage over a debate that is largely irrelevant. I do believe that both Monero and Boolberry have something to offer the community at large. I have, however, lost all respect for you and for Boolberry this evening, and I am saddened by this turn of events and the dishonourable behaviour I have observed.

Oh and as for responding to dga - if arguing over "the best" PoW algorithm was worth more than 20 seconds of my valuable time I would have responded. I respect dga very much, but I do not see a need for endless and ongoing PoW comparisons. We are not bound to CryptoNight by blood, and if we change in future you can bet it will be to something superior like a future iteration of Cuckoo Cycle and not to something functionally indistinguishable like "Wild Keccak". Rehashing that argument over and over is pointless.

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".

[othe]

b) Architectural changes that will require hardfork better to implement before launch

I largely disagree on this point, and I think it is fairly important.

It is better to be able to manage hard forks effectively with thoughtful design, good communication, broad buy-in, and successful execution (many of which ultimately reinforce the others). If hard forks become a "torment" (or worse are viewed as something that can't be done at all) this is a symptom of a much more serious problem with the development process and community that indicate paralysis, stagnation, and, likely, death.

Not that there was anything wrong with launching a CryptoNote fork with a different blockchain design from the start though (separate question).

There is a likely point of extreme stability, maturity, and near maximum adoption where further hard forks become both impractical and unnecessary. But as long as coin is young and in active development you had better plan for hard forks or you can't adapt and will likely be left behind. No one can make every important decision in advance.

This is theoretical though, as Monero hasn't delivered any hard forks yet. So we will see. If we fail to pull them off I think we will be in trouble.

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.

No its not; you dont need to wait on anyone, you simply make a block out where the hardfork gets active, lets say 1 month in the future. So people have at least a month time to uprade their software.
What it needs to do a hardfork is communication with the users and service providers and our communication with them is pretty good.

Funny enough that you will also have to hardfork as mentinoed in the XMR economy thread; when the blockreward runs out and we simply rely on tx fees, this won´t work in the next years, a minimum block reward is needed.

Sorry but its just naive to think that the current cryptocurrencies will survive the next 100 years without a single hardfork.

but it has some contradictions with crypto-currency nature (in my vision):

Says the one who decides which ring signatures to cut off in BBR...
It´s simple: the users will decide if they accept the changes or not.