[XMR] Monero - A secure, private, untraceable cryptocurrency

[GingerAle]

how I feel about choosing a crytocurrency based on availability of a GUI

https://www.youtube.com/watch?v=puo1Enh9h5k

(for those who don't want to click, its the indiana jones last crusade scene where they have to "choose wisely")

[1714841270]

1714841270

[1714841270]

1714841270

[1714841270]

1714841270

[onemorexmr]

how I feel about choosing a crytocurrency based on availability of a GUI

https://www.youtube.com/watch?v=puo1Enh9h5k

(for those who don't want to click, its the indiana jones last crusade scene where they have to "choose wisely")

but, but, but... there are gui's?
multiple....
even a very nice web-based one...

its an opensource project... who cares about something official?
if someone forks monero and adds a rpc-call i need i'd use it - but it wont be official

to be serious:
at this stage a gui is not really needed. its important that we have mymonero so not-so-tech-savy people can get on board in a trustless way (we need them, so lets make sure they dont get scammed).
anybody else can learn the few commands needed to start, receive and send transactions.

[Kuriso]

I'll just leave this here.

Don't forget that Monero was launched with the sole purpose of being a scam.  Original devs only did it for the money.  If the community didn't take it over and find a whale to back it, the coin would be dead right now. 

You are absolutely right. -snip-

Nice to know I'm right and not just spreading FUD or being a 'monero hater'.  Where is this stated in how monero got started?  I'd like to see some transparency around here.

[Johnny Mnemonic]

It's quite obvious that quote was taken out of context. Regardless of the reason bitMonero was created, its reward curve was never altered. The same cannot be said for darkcoin/dash.

Where is this stated in how monero got started?  I'd like to see some transparency around here.

The history is pretty clearly outlined here:
https://forum.getmonero.org/20/general-discussion/211/history-of-monero

[vokain]

What determines the per-KB transaction fee?

[smooth]

What determines the per-KB transaction fee?

The size of the transaction once it is encoded? I maybe didn't understand the question?

[smooth]

It's quite obvious that quote was taken out of context. Regardless of the reason bitMonero was created, its reward curve was never altered. The same cannot be said for darkcoin/dash.

Where is this stated in how monero got started?  I'd like to see some transparency around here.

The history is pretty clearly outlined here:
https://forum.getmonero.org/20/general-discussion/211/history-of-monero

Excellent, I was wondering where that was.

The rest of the quote for context:

You are absolutely right. The difference between this coin [meaning DRK] and that coin is that here, no one took over.

[vokain]

What determines the per-KB transaction fee?

The size of the transaction once it is encoded? I maybe didn't understand the question?

No, the size of the transaction is variable mostly upon the mixin count as far as I understand it, but what determines the fee implemented to check blockchain "spam"?

[smooth]

What determines the per-KB transaction fee?

The size of the transaction once it is encoded? I maybe didn't understand the question?

No, the size of the transaction is variable mostly upon the mixin count as far as I understand it, but what determines the fee implemented to check blockchain "spam"?

Oh there is a hard coded minimum of 0.01 currently, which is the recommended fee for <= 1 KB. Nothing lower than that will be forwarded. Eventually we would like to move to something more like Bitcoin 0.10's dynamic fees.

Miners can fill blocks with their own spam however they want but their reward will be reduced if the block size exceeds the median of the last N (I think 720) blocks. It would be pretty stupid to do this though since it will slow propagation and result in more orphaned blocks, even more so than with Bitcoin.

[onemorexmr]

Miners can fill blocks with their own spam however they want but their reward will be reduced if the block size exceeds the median of the last N (I think 720) blocks. It would be pretty stupid to do this though since it will slow propagation and result in more orphaned blocks, even more so than with Bitcoin.

as you mention more orphans: do you think that our fast blockrate may lead to more miner-centralisation in the future?

is the cryptonote protocol able to use things like 1BLT for faster block propagation?

i still dream of quite electric heaters or boilers; companies could gift them - users pay with their mined coins.

[smooth]

Miners can fill blocks with their own spam however they want but their reward will be reduced if the block size exceeds the median of the last N (I think 720) blocks. It would be pretty stupid to do this though since it will slow propagation and result in more orphaned blocks, even more so than with Bitcoin.

as you mention more orphans: do you think that our fast blockrate may lead to more miner-centralisation in the future?

Yes probably. It should probably be slowed down some when we do a hard fork for other things like MRL-0004. The one minute block time was one of those things that TFT did anyway despite everyone else disagreeing. It was never intended that way (except by him, for god knows what reason).

is the cryptonote protocol able to use things like 1BLT for faster block propagation?

Yes there is no reason that would be any different than Bitcoin. There are some simpler improvements too, like just sending a few bytes of the txid with each block instead of the whole thing (most of the time transactions in a block have already been sent).

[onemorexmr]

Yes probably. It should probably be slowed down some when we do a hard fork for other things like MRL-0004. The one minute block time was one of those things that TFT did anyway despite everyone else disagreeing. It was never intended that way (except by him, for god knows what reason).

good idea.
are there any discussions / opinions about what may be a good blockrate?

(i assume you'll keep the social contract intact. eg 2min blocks - doubled reward)

[smooth]

Yes probably. It should probably be slowed down some when we do a hard fork for other things like MRL-0004. The one minute block time was one of those things that TFT did anyway despite everyone else disagreeing. It was never intended that way (except by him, for god knows what reason).

good idea.
are there any discussions / opinions about what may be a good blockrate?

(i assume you'll keep the social contract intact. eg 2min blocks - doubled reward)

Maybe 2, maybe 4. There was one view that it should be >5 (I don't disagree in the abstract) but 8 seems a bit high. Yes about the social contract and that's what makes anything that isn't a power of two a bit tricker to stick with the same curve (but not impossible). With power-of-two it is trivial.

[fluffypony]

We're having a Monero Meetup in Berlin on May 24th, myself and David Latapie will both be there (he's promised to wear his gangster outfit).

All are invited: https://forum.getmonero.org/14/events/237/monero-meetup-berlin-germany-may-24th-2015

[smooth]

he's promised to wear his gangster outfit

Better vote for him, or else: https://bitcointalk.org/index.php?topic=723764.0

[BitmoreCoin]

Yes probably. It should probably be slowed down some when we do a hard fork for other things like MRL-0004. The one minute block time was one of those things that TFT did anyway despite everyone else disagreeing. It was never intended that way (except by him, for god knows what reason).

good idea.
are there any discussions / opinions about what may be a good blockrate?

(i assume you'll keep the social contract intact. eg 2min blocks - doubled reward)

Maybe 2, maybe 4. There was one view that it should be >5 (I don't disagree in the abstract) but 8 seems a bit high. Yes about the social contract and that's what makes anything that isn't a power of two a bit tricker to stick with the same curve (but not impossible). With power-of-two it is trivial.

4 min should be OK. At present, there are not much transactions going on with XMR. Most of the blocks are mining rewards only. When XMR gets used more in the future, we can reduce the block time to 2 min, then 1 min, even 30s when internet is much faster resulting fewer orphan blocks.

[onemorexmr]

4 min should be OK. At present, there are not much transactions going on with XMR. Most of the blocks are mining rewards only. When XMR gets used more in the future, we can reduce the block time to 2 min, then 1 min, even 30s when internet is much faster resulting fewer orphan blocks.

IMHO blockrate changes require a hardfork and should not be done regulary.
the tps amount can scale with blocksize - which is already dynamically

but, i prefer 4min too

[Eastwind]

4 min should be OK. At present, there are not much transactions going on with XMR. Most of the blocks are mining rewards only. When XMR gets used more in the future, we can reduce the block time to 2 min, then 1 min, even 30s when internet is much faster resulting fewer orphan blocks.

IMHO blockrate changes require a hardfork and should not be done regulary.
the tps amount can scale with blocksize - which is already dynamically

but, i prefer 4min too

This block time change can be coded and 1 year in advance so that people have plenty of time to respond.

[fluffypony]

you guys are always pointing out how the project is basically unfunded and you do great work under those conditions no doubt. but i just want to do what i can to help with this situation for 2 reasons, for the good of monero, but also because you guys should be compensated for the work you do. and the thing is, i just dont think that panhandling is ever going to get you the sort of consistent and appropriate compensation you should be getting, and monero should be getting.

We've been working on adding some needed functionality to the forum, and our next major task we're going to tackle is the funding system. The idea is:

1. Users / developers / anyone will pitch an idea in the Ideas section of the forum. This is already happening.

2. After some discussion it will be moved by one of the administrators (currently the Core Team only, but that would change in future) to the Open Tasks section of the forum. No tasks have been moved as yet.

3. Developers (including the core team, and initially probably only the core team for simplicity) will pitch against each of these open tasks. Later on I would expect that there would be more people / teams pitching against tasks, and the most competent / available / reasonably priced will be the one the community will veer towards.

4. Once the developer / team has been selected to complete the task it moves to the Funding Required section of the forum, and it is opened for funding.

5. Funding will be to a core team controlled address with a payment ID for that particular project/task, and there will be a funding progress bar. This information will be mirrored over to a funding page on the website that shows the funding progress per project/task.

6. When funding reaches 70% (for smaller tasks) or 30% (for larger and longer tasks) it goes into the Work in Progress section and work begins.

7. Funds are dispensed by the core team on a regular basis and only if there is actual progress / commits / whatever, so it doesn't go into a black hole.

Advantages of this approach:

- the core team's oversight role can eventually be replaced by a group selected from the community at large, so as not to have a stranglehold over things

- the core team's escrow role can eventually be replaced by a multi-sig system (2-of-3) where the signatories are the core team, the oversight group, and the recipient, so the recipient can't spend those raised funds without the involvement of one of the other 2 signatories

- this isn't limited to dev tasks, and things like "fly David Latapie to speak at a conference" or lobbying or PR or advertising can all have tasks created and funded

- funding is direct and specific to tasks instead of going into a big black hole and hoping for the best

We expect this system will still take us another short while before we can put it live, but we're already crunching away at the functionality for it (and this also further emphasises why the forum couldn't just be SMF with a theme;) )

[smooth]

4 min should be OK. At present, there are not much transactions going on with XMR. Most of the blocks are mining rewards only. When XMR gets used more in the future, we can reduce the block time to 2 min, then 1 min, even 30s when internet is much faster resulting fewer orphan blocks.

IMHO blockrate changes require a hardfork and should not be done regulary.
the tps amount can scale with blocksize - which is already dynamically

but, i prefer 4min too

This block time change can be coded and 1 year in advance so that people have plenty of time to respond.

(Somewhat) short term there is going to be a hard fork for the anon stuff and maybe a few other cleanup items, so whatever change we decide on short term can go in with that. The other question was reducing it in the future given other improvements like IBLT or whatever. Obviously that sort of thing can't be scheduled in advance without knowing what those other improvements will be and when they occur.

But ultimately we can't fear progress to the point of stagnation with a coin that is very much in-development and will be for some time to come. When Bitcoin was in early development satoshi did a bunch of hard forks. It was only later they became a big deal, and that's perfectly reasonable given the maturity curve.

Obviously any such forks (other than in case of emergency) will be carefully planned, announced well in advance, etc.