Preventing gotchis listed for rental from being able to channel

Ok so the toggle idea to stop a renter from channeling an owner’s gotchi could be a possible exploit? So is it off the table at this point? I am kind of confused because if it was no longer able to channel would not the subgraph update to show this? If it has been exploited, I have no reasons to protest the patch but it was never presented here in that fashion. From what was given here, there has not been one verified instance of this ever happening since the contract has gone live and the only evidence that was given showed where a wallet that looks like it was 'botting both the rental contracts and the Gotchiverse was shown. Again if you feel like this is an issue, please fix it and next time could you just make an announcement after it was done like you have for so many other tweaks because this has been F.U.B.A.R. since day one. :sweat_smile:

Honestly, this is a bug fix. Gotchis are locked for a reason, people being able to do this was not the intended behavior of the system.

If I figure out some exploit tomorrow, we discuss how to plug the hole, and cant find a negative for our solution… I would hope PC just plugs the hole. If it turns out to be a can of worms, so be it… then we do the whole multiweek vote thing.

And yeah, I agree that we should be better about how we present things… This is an exploit, not a proposal or feature add. It sounded like a feature, because he was suggesting a solution, but really, this is “system not working as intended”

While we’re at it… got any more “FUBAR since day one” things that haven’t been exploited, that could be? I’ve noticed the bazaar is sketchy lately… we could certainly use something on there that makes sure it’s displaying the correct wearables for the gotchi, before a sale.

2 Likes

And that’s what was getting me because it was presented that way. So I just started asking questions and then gave possible solutions but that seemed to get them upset with me for questioning. :sweat_smile:. Truthfully IMO if it was not a subgraph delay issue, the only one’s affected would be the persons botting new rental listings before they are posted since rentals are listed/displayed using subgraph. If PC thinks this could be exploited, then lets plug it and announce it when version 3.19 hits the Gotchiverse :grin:

OK, this just happened to me… it’s 20 min after reset, and I rented it when it said it was posted 17 sec ago, so this person clearly posted, then channeled.


image
The owner - 0xa33Aa58FD2795eA89a84C19CACDad50915194980
It looks like what might be happening is botted channeling + relisting?

:exploding_head: WOW so 20 mins after reset you found a rental that said it was able to channel but when you tried to channel it failed. Hmm you might be on to something with that botted channeling and relisting :thinking: Dang whomever it is does not look like they are hurting on funds :sweat_smile:

1 Like

And this is how you get caught botting channeling… I’m very curious what the response will be, considering that when I asked if I could do it, I was told my gotchiverse privileges would be revoked, if I got caught.

I have a feeling they intended to list it at .1 ghst with no channeling, but their bot is too fast.

I’m for implementing this, but I’m gonna play lickquidator’s advocate here. Has anyone bothered to look at the subgraph to answer the most basic questions regarding this change, i.e. how much of an impact it will have for both owners and borrowers?

  • A: How many times (total and as a percentage) has an owner channeled their Gotchi within 5 min after creating a lending listing?
  • B: Only looking at the subset A: How many times (total and as a percentage) out of those was the listing accepted within the first 5 min after it was created?
  • C: How many times (total and as a percentage) has an owner channeled their Gotchi later than 5 minutes after creating a lending listing?
  • D: How many times (total and as a percentage) has an owner channeled their Gotchi within 5 min prior to creating a lending listing?

This will answer key questions like:
A = How many times was this exploit used (intentionally or unintentionally)?
B = How much of a negative impact did it have? I.e. how many people might have fallen for it.
C = How many owners might be negatively impacted by the change, even though they do not have any bad intentions?
D = How many times was the subgraph delay exploit used (intentionally or unintentionally)?

The only reason against this would be related to C. When Gotchi Lending started, it was quite expensive on gas (not sure if you guys made some improvements to that since day one, since I haven’t used Gotchi lending in a long time). So you basically needed to put ~0.1 GHST upfront cost just to get back your gas for listing + claiming back. Now lets say someone listed at an unattractive price. He listed 2h before reset and he listed for 1h lending duration. His intention was to rent out their Gotchi before the reset. But nobody accepted. To safe gas on cancelling and relisting the Gotchi, he channels his Gotchi himself after the reset. In this case e.g. people had 1h to bite, as the duration was for 1h, before he channeled. So this could not be called an exploit…just a greedy owner who priced his Gotchi too high. Yet, those people (however many there might be) would be negatively impacted by having to cancel and relist, costing them gas.

Again, just playing lickquidator’s advocate here. But making changes like this without a proposal AND without looking at (or at least without presenting) the relevant data looks unnecessarily sus.

1 Like

Maybe we should just put a random number of blocks on after a listing request, and the listing doesn’t go in until that many blocks… this might slow down the bots that rent everything good before we even see it and it might protect us from having to ask prominent community members why they are getting caught botting, and the awkward conversations it causes(I think I know who it is, and this is not good)

2 Likes

Happened to me twice last week.
The first time I convinced myself, I have been too fast.
Second time I realized, I have been too slow to grasp, that someone else is evidently “too fast”.
First I was pissed… then pity took over:
someone who has to resort to scamming others out of 0.1-0.2 GHST probably is a poor, desperate soul, who really needs the money.

1 Like

Wait so is this a “they posted THEN channeled” or a “they are botting channeling THEN posting” situation? If it is the latter, this contract tweak will have zero effect. I am really shocked that any botting inside the Gotchiverse has been allowed regardless whomever it may be and also a little stunned that it somehow has gone undetected.

It could also be a combo of some renters that send the transaction in one window and have a claim and close ready to go in the other, and their next rental lined up in a 3rd… maybe its the result of nofute VS the vault listing bot :smiley:

Lol those could be other…factors but i think you are on to something with a “minimum” block amount to identify the gotchi’s status change when listing rentals. IMO around 30 should not be seen as a problem that way once the posting actually list it will/should have the most updated information if there is not a subgraph delay more than that.

There are more ways to abuse the situation, that what we are experiencing, and I think what’s happening right now is just the vaults listing bot rubbing up against a bunch of people trying to channel ALL the vaults altars in the first 30 min after reset. I’m going to speculate and say the vault upgraded their listing bot within the last three weeks, and it’s so on point that it’s like having dual petting services, which… that’s a bit much. There is literally no reason right now for people to be super worried their gotchi is rented out non stop. It’s a game of times and rotating schedules, with a 24 hour window, not some race :smiley:

I have a solution:

The rental and listing markets(any market where we have a “lock” feature on the asset) need to have a buffer. Instead of listing everything immediately, the intended listing goes into a cue, that holds everything until the subgraph has been synced. It does not assign listings numbers until the very end, and it posts everything it has at once, when it determines that the subgraph is displaying exactly what the listing is for.

While your listings are cued, you get a placeholder number, that you can use to cancel if you fat fingered or change your mind. This number is unrelated to what the listing will be, it’s just your place in the cue. This means that the bazaar bots can’t front run the graph by seeing the orders as they go in and watching for the listing. They will only know what is in the next batch, and the postings should be done by a batch operation and be blind until they hit the blockchain. The message to post would be easy for the graph nodes to sync, and this would even the playing field a LOT in the humans VS bots battle.

Those are the side effects you get, by fixing the source of a display issue instead of just adjusting the knobs on the display.

We’re going to need cuing systems on almost everything cool, actually. This might sound like more work, but it’s needed technology for everything we’re doing later.

You need a cue for matchmaking PVP, cues for gated content like dungeons, cues for withdrawals from verse to blockchain, cues for onboarding free to play players, farming itself is essentially a cue for your returns… this means that this mechanic is at the core of everything, and that like glitter being a token for time, syncing cues and batch updates are our middleware/backend optimization goto, because if used properly, they greatly reduce gas use/congestion, and actually improve the user experience by giving a predictable delay that lets the data reporting infrastructure do its job efficiently.

1 Like

:thinking: sounds interesting…


Still happening.
0xD3B2656abf824Fb402E47Bb6D09f42e90f2C5898

The common factors so far are “vault rental”, “extra cheap upfront” - so… it is appropriate to assume that this is not intentional, as noone is griefing like this for .2 ghst… at least, I should hope not.

I don’t think anyone has looked into that yet, but maybe the DTF would be open to funding an analysis so we have better data to inform the proposal.

From the contract side, the implementation is ready. But we’re not going to implement the change if it’s controversial (which it appears to be, somewhat).

So its a proposal now? :man_shrugging:

You complained enough that the devs didn’t want to just make the change.

Well ACTUALLY I complained because of the way that YOU presented it. Also there has NOT been any data presented as to address any seen or unseen impacts this may cause, but i see that you just kind of skipped that part :sweat_smile:

No, you had no issue with how I presented it, you just thought because it didn’t impact enough people that it wasn’t worth fixing.

Firstly, IMO this is actually a Non-issue being that it has only happened to maybe 2 or 3 renters since the renting contract has gone live and you have not presented any valid reasons that this needs to be done at this time.

I’m not going to engage with you anymore. Good luck.