<dEBRUYNE> Devs: Are there plans to address this matter? -> https://bitcointalk.org/index.php?topic=583449.msg11458701#msg11458701 (read the quotes as well)
<moneromooo> Not a dev, but.. yes.
<dEBRUYNE> Doesn´t matter moneromooo, you´re a significant contributor as well! Anyway, thanks for clarifying
<moneromooo> Annoyingly, I cannot remember where I learned this from.
<fluffypony> that's covered in MRL4, afaik
<fluffypony> we're basically just going to have a decimal cut off below the dust limit
<fluffypony> so mainchain won't really be well suited to micro-micro-payments :-P
<fluffypony> (also the dust limit will be lowered so as to provide enough flexibility in this)
<dEBRUYNE> with 2 decimals Monero has to be worth quite a lot :P
<fluffypony> dEBRUYNE: dust limit will be disconnected from the fee
<fluffypony> so essentially you'll be able to send 0.0001 XMR, if you're willing to pay the 0.01 XMR fee
<dEBRUYNE> I see, thanks for clarifying! Can I post this on bitcointalk?
<dEBRUYNE> I am sure some other people are curious as how this is going to be addressed
<palexander> fluffypony, does that require hardfork?
<fluffypony> well this is what has generally been discussed, but sure, you can also point to MRL4 as a reference point
<fluffypony> palexander: yes
<dEBRUYNE> fluffypony: So we first need a hardfork to address this and then one after to address the minimum mixin 3 right
<dEBRUYNE> ?
<fluffypony> why not do both in the same fork?
<moneromooo> And switch to the sqrt mixin scheme along with it ^_^
<palexander> Whats the cost for sqrt mixin vs. regular mixin?
<palexander> By cost, I mean does it increase transaction size, etc.
<moneromooo> From what I understand, it's a way to store ring signatures with space requirements in O(sqrt(N)), rather than O(N). I think it was sqrt. log would be too good to be true.
<moneromooo> I don't know about the constants involved.
<moneromooo> There was a post by... hmm... Adam Back ? About it.
<palexander> ahh, yes.  I read that post.
<moneromooo> Oh, wait, no, this one was about a linear reduction.
<palexander> In fact, I was going to ask about that here in a few minutes.
<moneromooo> A paper by a Japanese cryptographer. Can't recall the name.
<palexander> Yeah, adam back's post was about reducing the transaction size
<dEBRUYNE> fluffypony: Articmine said the matter I stated should be addressed first in order to implement mixin 3 properly, hence my statement :p
<dEBRUYNE> I am not technically capable to verify it myself
<palexander> Funny how this whole cryptocurrency think has really brought mathematicians out of the woodwork. :-)
<palexander> think=thing
<dEBRUYNE> moneromooo: I think this is what you were referring to -> https://bitcointalk.org/index.php?topic=972541.msg10842017#msg10842017
<moneromooo> trim_white_peerlist trims the grey peerlist; trim_grey_peerlist trims the white. I wonder if t's just some WTF or if I'm missing something subtle...
<palexander> dEBRUYNE, thanks for posting that.  I was looking for that post the other day.
<fluffypony> dEBRUYNE: he's misunderstanding the MRL4 changes
<fluffypony> after we implement MRL4 *there will be no more unmixable outputs*
<dEBRUYNE> I see, will make a small summary for bitcointalk of this conversation
<moneromooo> No more unmixable outputs created ? IIRC previous can still be spent at mixin 0 ?
<moneromooo> previous dust
<fluffypony> moneromooo: that's inputs
<moneromooo> Oh OK.
<fluffypony> the outputs of a dust clearance transaction *must still be mixable*