pull down to refresh
152 sats \ 8 replies \ @ek 12h \ on: đź“Ł Community Feedback Requested: Predyx Fee Structure oracle
Unrelated feedback: you use way too much AI for your posts. I don’t read any of them (including this one) because they are boring, full of marketing speech and have no “soul.”
If you didn’t write it yourself but just prompted for it, I don’t feel like it’s you who is talking to me, but just some statistical model as a proxy, that is coming up with words that sound nice but aren’t your words.
It also makes me wonder how much you care about your users if you don’t come up with your own words for them or if you even read the output yourself before you post it. Maybe I should also not have wasted my time trying to come up with my own words here but just reply with some prompted, generic text, so you can see how it feels?
Regarding the fees: you should fix the underlying problem which seems to be that you don’t handle transactions correctly.
Did you switch from MongoDB to Postgres?
Yes, I do use AI heavily - because I thought it makes it more readable and clear. But I guess its the other way round as you rightly mentioned "boring and have no soul". Thanks for the honest feedback - will try to use less of it.
Honestly I do care a lot about the users that's why I'm mostly available here in SN to get feedback and market announcement etc. I do tell the AI what to write for example for the above post my prompt was: "Make an announcement of new fee structure of 0% buy, 1% sell, 1% buy - as the previous fee structure was too high." - Somehow unconsciously I don't feel very confident in creating formal announcement like above. But I get your point - It just comes off as I don't care about the users. My own insecurity I guess.
Regarding the fees: you should fix the underlying problem which seems to be that you don’t handle transactions correctly.
Can you please elaborate more on "not handling transactions correctly" - what are we doing wrong?
reply
No we didn't switch from mongo to postgres. We learned that using atomic transaction solves the problem of double-spend ex:
$inc: { balance: -100 } - since then we do not have any double spend problem. Now we also use Layer7 API gateway for rate-limiting and throttling to get a first level protection for parallel API attacks.reply
Somehow unconsciously I don't feel very confident in creating formal announcement like above. But I get your point - It just comes off as I don't care about the users. My own insecurity I guess.
Okay, I get that! And thanks for letting me be honest with you!
But do your SN posts have to be formal?
I don't know how others feel, because nobody else mentioned this issue, but I like your replies a lot more because then I actually feel like a human is talking to me. Is it not possible to announce something like you reply?
Can you please elaborate more on "not handling transactions correctly" - what are we doing wrong?
You mentioned in #1008195 that the real reason was an attacker that was exploiting or trying to exploit you via double sells. Since you introduced fees because of that reason, I assumed he was successful? But you also mentioned that you fixed it in the software without fees? 🤔
Anyway, I thought you had issues with concurrent transactions. This seems to be a good read.
reply
But do your SN posts have to be formal?
Thanks for breaking my fear - I think its same like public speaking fear. (In my mind I always thought from my own limitations) I'm going give writing myself a try w/o use of AI. Lets see how feels.
You mentioned in #1008195 that the real reason was an attacker that was exploiting or trying to exploit you via double sells. Since you introduced fees because of that reason, I assumed he was successful? But you also mentioned that you fixed it in the software without fees? 🤔
The double-spend or parallel attack issues have been fixed.
But in this (the current spam events) case the spammer/attacker is draining us with network fees. We do not charge any fees on sell to LNAddress directly. However there is a network fees that we have to pay everytime the user sells to LNAddress directly. If he sells to internal Predyx/lnbits wallet then this is not a problem, as the internal wallet transfers don't go through the network but just database updates (its a feature of lnbits) - I hope I was able to explain the above issue clearly.
Anyway, I thought you had issues with concurrent transactions. This seems to be a good read.
Thanks for sharing the link, will give it a read.
reply
However there is a network fees that we have to pay everytime the user sells to LNAddress directly.
Oh, right, you should definitely charge users for network fees and not pay them out of your own pocket, else you're opening yourself up to fee siphoning attacks.
If that's the reason for the fees on selling, wouldn't charging them for network fees be the fix you're actually looking for? If you're still paying for network fees out of your own pocket, this doesn't actually fix fee siphoning.
reply
Thanks for "fee siphoning attack" link - I'm hearing it for the first time. Will implement the network fees for LNAddress payouts.
Also another motivation for adding the fees are to incentivize the market creators. We have plans to allow user created markets in few weeks. As you may already know every market created in LMSR must be subsidized with liquidity. The between 33% - 66% of this liquidity gets lost as the market comes to conclusion based on how thinly the market is traded. And if the market moves only in one direction, then almost all of the liquidity is lost.
Wanted to be prepared for the user created markets - by adding fees and fine tuning it to optimal level so that the user is incentivized to create markets.
Next we also wanted to get ready to allow 3rd party to provide liquidity with an incentive to earn fees. There will be no motivation to provide any liquidity without the potential to earn some fees.
reply
It seems like the optimal fee structure will have a fixed component to cover the fixed transactions costs and an exit fee that’s proportional to the wager to mitigate attacks.
Thanks for "fee siphoning attack" link - I'm hearing it for the first time. Will implement the network fees for LNAddress payouts.
Also created a post about it: #1008424
As you may already know every market created in LMSR must be subsidized with liquidity. The between 33% - 66% of this liquidity gets lost as the market comes to conclusion based on how thinly the market is traded. And if the market moves only in one direction, then almost all of the liquidity is lost.
Yes, I remember talking about this with @kr when I was still working on delphi.market!
Wanted to be prepared for the user created markets - by adding fees and fine tuning it to optimal level so that the user is incentivized to create markets.Next we also wanted to get ready to allow 3rd party to provide liquidity with an incentive to earn fees. There will be no motivation to provide any liquidity without the potential to earn some fees.
Ok, makes sense