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

not that Monero needs another thread, but I made a new technical discussion thread.

https://bitcointalksearch.org/topic/xmr-monero-improvement-technical-discussion-1139756

you come in there with talk of money, I delete it.

Trolleros devs think that the important is to have a CLI, lol, no upgrade is needed.

thats right. And therefore no one should "invest" in monero because the most important aspect of bleeding edge fintech is whether the wallet software is cute and bubbly and grandma can use it.

/sarcasm

but monero still not have an official wallet gui, isnt?

If you want a brief and consice answer, take a look at this link -> https://moneroeconomy.com/faq/why-monero-matters

In addition, read the sidebar at https://www.reddit.com/r/monero (the green Why Monero?).

This is also a good read -> https://www.reddit.com/r/Monero/comments/2u4m2u/the_thee_pillars_of_monero/

Finally, if you have a spare 30-40 minutes, just watch this presentation. It also makes some comparisons with Bitcoin -> https://www.youtube.com/watch?v=GEVm1dMn5Ks

Do your own research. Asking people's opinions is not research.

Hrm, you would also have to make the floating minimum a range, not a fixed value.

Ff the precisely calculated minimum is 0.01211 xmr / kb, and by the time your transaction is made and sent to the network, the new precisely calculated minimum is 0.01213 xmr / kb, that won't work.

instead, you would have some range around the precise minimum. This range itself would have to be dynamic, but that could be easy... just use the rate of the delta for the minimum. I.e., if over n blocks the minimum moved 0.0004 xmr, then thats the range. (or something like this)

gotcha gotcha. I think I'm picking up what you're putting down.

Basically, you're saying that if some kind of algorithmic floating number were to be implemented, we would have to find a way to harmonize it across those 4 different elements. Well, really, elements 1,2, and 3. What miners decide ( #4) has to be >= 1,2,3 .

And changing the fees would require recompiling the source code.

I would imagine it would work something like this:

When a block is mined, a new piece of data (activity) is stored in the header. This piece of data (calculated by the miner) is something like 

activity = (sum of number of transactions in n recent blocks) X (total amount in transactions in n recent blocks) / (n recent blocks)

We'll have to figure out exactly what the function X is.

When new block is made, every miner can validate that activity value was properly calculated.

(1) When determining whether to propagate a transaction, the daemon can use the most recent activity value in its calculation of minimum fee.

(2) When determining whether to include a transaction, the mining code can use the value in its calculation

(3) When making a transaction, simplewallet can use the activity value to make its calculation of minimum fee.

Sure, we've added more data to each block, but I think Monero is fond of the notion of increased protocol utility vs. concerns over blockchain size. And yes, Monero is sentient and can be fond of things.

Yes exactly, not only the mempool but bandwidth used by every node to relay the transactions.

I'll go back and fix the typo but the idea is that if you broadcast a transaction it should have a significant chance of actually being mined.


I'm not sure I would agree that one or another is "primary" protocol-induced. They are all important to the protocol (the process of mining, for example, is certainly part of the protocol), but they are different and interrelated. They're all per-kb in the current implementation.

So the fee that I'm talking about would be #1 - the fee required for relay by nodes. I'm not sure I'm parsing what you write in the above bold -  so the spammer could spam just by bloating the mempool? I think the confusing part is the mis-type of "much much", which could be "much less" or "much more", and this is a key piece of data.

I'm assuming its much less.

blue text = but couldn't each individual node recalculate the minimum value based on data on the blockchain? So then all nodes will be in agreement, because they're all making the same calculation off the same blockchain.

If I'm reading you right, the primary protocol-induced fee is #1. Is this fee what I understand as the per-kb fee?

This is a useful and interesting effort but keep in mind there are at least four different tx fees:

1. The fee required for relaying by nodes.

2. The default fee set in the code for miners to include a transaction.

3. The default fee set in the code for those sending a transaction.

4. The actual fee at which miners include transactions in practice.

The first is a network function that prevents spamming the p2p network as a DoS attack. It should not really be much less than #4 because that allows spamming the p2p without any real cost (the spammer wouldn't actually pay the fee because the tx wouldn't get mined). It can't be changed (either higher or lower) by individual nodes because if they violate the rule expected by other nodes they will get disconnected.

The second is a default in the code and miners can change it if they want (currently this would require recompiling the source code, but other options may be added later), though setting it lower than #1 would not result in any more transactions being mined since they won't be sent over the p2p UNLESS the miner gets these transactions via another channel, or creates them.

The third is a default in the code and users could change it if they want (currently this would require recompiling the source code, but other options may be added later). If this is set lower than #1, the transaction will be rejected by nodes.

The fourth is entirely a market phenomenon that is a balance between supply, demand, and the fee policies set by users and miners.


EDIT: fixed typo "much much" -> "much less"

Not needed for sending out from polo unless you are sending it to another site/wallet that requires a payment ID (for example to another exchange)


You can't tell the balance of an account without using a wallet  (or client or whatever you want to call it). Even if you have the TXIDs or payment IDs and can find them on a chain explorer, you won't know how much is the actual payment and how much is change, nor which payments sent there have been spent.

This is different from Bitcoin or other transparent blockchains where each address has a public "balance"


TXID is generated by the sender (as a hash of the transaction constructed by the sender). Payment ID is just an arbitrary 64 character hex string and can be anything (specified by sender) but the two are unrelated.

Poloniex has transaction ID (optional) prompt to send moneroj out.
1. Is it really necessary or public address is sufficient?
I am trying to compare Monero with bitcoin and it looks like that you cannot see what is in a particular wallet by just using the public address.
Is this correct?

2. If #1 assumption is correct, apart from logging into the account (wallet), how one can ascertain how much moneroj the account has?
By using all transaction IDs if you have them recorded separately?

3. If I did not provide a transaction ID, just the recipient wallet address, where is transaction ID generated-on the sender site (Poloniex) or wallet side (for example, getmonero)?

For Monero frequent users, these are probably naive questions, but I find differences from bitcoin sufficient enough to ask.
Thanks.

I have been hearing a lot of good things about Monero. I am going to get a few to hodl.

Well, now that thats all over, lets talk about something fun!!!

I've been trying to wrap my head around how to convert the fee calculation to something dynamic that wouldn't require human intervention.

As far as I understand, the primary reason the fees exist is to prevent blockchain spamming (and mining incentive). So Monero has some minimum fee thats based on the size of the transaction. I'm sure you've noticed how this works if you've tried to clean up some dust using Moneromoo's recent simplewallet enhancements (2.3 XMR to cleanup 5xmr of dust wuuuuut)

Currently, the fee is 0.01 xmr / kb as writ here: https://forum.getmonero.org/1/news-and-announcements/91/monday-monero-missives-17-november-2nd-2014

Now this is all fine and dandy except when Monero shoots to the moon (1 xmr = $1000), because an increase in price doesn't mean the size of the transactions will decrease. A transaction to send 0.045 XMR will use the same space (well, probably more depending on mixin availability) as a transaction to send 45 XMR (more or less).

Obviously, the easiest solution is to modify the code by hand (the devs intervene), and there will be plenty of incentive to do so - the cost of transacting will decrease the utility of Monero - the coin has become worth a lot, but it is really expensive to use, so people just hold it. But when humans intervene, you end up with all the nonsense associated with humans. Miners might not want to switch because they're raking in profits. The monero-as-asset crowd will rally for not changing the protocol because transaction friction could actually increase the value of an asset ( perhaps ).

All-in-all, the modifying-the-fee-using-human-intervention is the antithesis of cryptocurrency. Again, the goal of cryptocurrency is to remove as much of human element as possible.

So, how could we do that?

I don't think its possible to somehow link the protocol to some type of oracle - i.e., the protocol somehow gets data input from some external source. For example, you could imagine the protocol gets a feed from some XMR / fiat exchange. I don't think this is possible primarily because it depends on factors exterior to the protocol.

I think we would have to stick with data that exists within the protocol / blockchain. Specifically, I think these are the data we can use:

t = Transaction frequency = number of transactions per block
a = transaction amount = the amount of XMR actually transacted in a given transaction


Using these data, I think something could be written that would achieve goal of increasing the XMR cost of a transaction when fiat value is low, and decreasing the XMR cost of a transaction when fiat value is high.

Essentially, when the transaction frequency is low and the transaction amount is high, one could infer that the fiat value of XMR is low.

Conversely, when the transaction frequency is high and the transaction amount is low, one could infer that the fiat value of XMR is high.


Obviously, some sort of rolling window would be used to aggregate an average of these data.

And fluffypony proceeded to come down from the mountain, and gaze upon the people below. And his words were "hello people!" yes, those were his words, we promise, that's actually what he said. And fluffypony proceeded to take his outer garment and rip it in two, for it was hot and he realised he didn't need to wear a jacket in this weather. And fluffypony raised his staff up high, and then remembered what happened last time and packed his staff away. And fluffypony's eyes gazed out upon the people below, and with a loud voice he declared: "stop spamming altcoin discussion section with Monero." And lo, the people fell upon their knees, and wept loudly, for they were "hurting it" and that was bad and they should feel bad. Thus is was that in one night the fluffypony vanquished the counter-trolling trolls, and he looked upon his work and it was good, but also there were some fiddly bits he needed to neaten up, so he made a note to do that in future when he had time, not that he ever had time because he was so busy and then things just kept piling up and how was he ever going to finish it and why are you rushing me I still have three things to do on my list before we can leave and what do you feel like for supper honey and are the dogs outside and can I put the alarm on so we can go.

PDF: https://cloud.getmonero.org/index.php/s/sVYp10YR6U09DOU

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

I think the powerpoint for this is kicking around. I'll see if I can find the link.

I want to give a presentation to 20+ devs at work on Monero for one of our weekly "tech talks". Can anyone point me to a powerpoint presentation that would be the most up to date and a decent amount of technical content?  This would ideally be something that has been presented before and had a good response from technical types. TIA.

It is fairly hard if not impossible to avoid. There is always some way to encode a small amount of information in transactions, using hashes, amounts, etc. In Monero you can use any Payment ID you want so that gives you 32 bytes per transaction to work with even without any of these tricks or special code.