Avatar
KoalaSat
645681b9d067b1a362c4bee8ddff987d2466d49905c26cb8fec5e6fb73af5c84
🤖 https://learn.robosats.org 🔔 https://github.com/KoalaSat/pokey 🛜 https://github.com/KoalaSat/samiz 🤝 https://p2p.band 8FCD BF57 4CCF D73D B68B  00CC 2F7F 61C6 146A B157

It's a pre-rekease I just wanted to test first the loop got fixed. I'll update it to a real release soon

I created a pre-release for the next version of Pokey, but first I need to confirm that infinite loop with Amber got really fixed.

Anybody facing that issue willing to test? https://github.com/KoalaSat/pokey/releases/tag/v0.0.7-alpha

Replying to Avatar fmar

Is Robosats a Scam?

After completing several successful trades with different coordinators on Robosats, I think it's a promising platform with great potential. The concept is appealing, especially as a non-KYC exchange tool, and I genuinely hope it gains more users and achieves long-term success.

However, I've recently experienced situations where I felt I was unfairly penalized, resulting in the loss of my fidelity bond for posting an offer. So far, this has cost me around 30,000 sats.

Here are the offer settings I used:

Public duration set to 23:59

Escrow/Invoice time set to 8:00

These settings should ideally allow you to sleep without risking your bond. If someone accepts your order right after you've gone to bed, the 8-hour escrow time should give you enough buffer to wake up, pay the invoice, and complete the trade.

The issue is that if someone takes your offer close to the end of the public duration—say, with only 1 or 2 hours left—the 8-hour escrow timer does not extend the overall duration of the offer. If you’ve gone to bed with less than 8 hours left on the public timer, you might have less than 8 hours to pay the escrow invoice before the offer expires and your bond is forfeited. This essentially penalizes users for not being able to respond instantly.

This setup seems flawed, as it forces users to stay vigilant during sleeping hours, risking money if they can't respond quickly enough.

I’m unsure if this issue varies by coordinator. Most recently, I noticed this with the Temple of Sats coordinator, but I believe I’ve had similar issues with others.

If this is the intended behavior, it raises concerns about potential bad actors using automation to take orders right before expiration, betting that the trade creators won’t respond in time—causing their bonds to be lost.

Has anyone else experienced this on Robosats? Any advice on managing it?

nostr:npub1v3tgrwwsv7c6xckyhm5dmluc05jxd4yeqhpxew87chn0kua0tjzqc6yvjh

We tested all possible combinations because, as I said yesterday, the behavior described on the post were not intended.

I was not able to reproduce it even creating and waiting for a real 24h + 8h order. These are the steps I validated and confirm with multiple combinations:

- Robot1 creates an order with a 23:59h duration set and a 8h escrow/invoice wait time.

- Robot1 locks its bond and the order goes public

- After 21h public, Robot2 takes the order

- Robot2 locks its bond

- Robot2 completes all steps and just wait

- The initial 23:59h duration just passes and nothing happens because there is still 5h left from 8h escrow/invoice wait time

- Robot2 only lost its bond after the 8h escrow/invoice times up

That said, if anybody finds out this to be different please intermediately report it to your coordinator.

nostr:note1vwmaxu20cavvn4fe6yf9qgplfrd3jecph3g89vycj4gzk0ya9qlsycwet3

Replying to Avatar fmar

Is Robosats a Scam?

After completing several successful trades with different coordinators on Robosats, I think it's a promising platform with great potential. The concept is appealing, especially as a non-KYC exchange tool, and I genuinely hope it gains more users and achieves long-term success.

However, I've recently experienced situations where I felt I was unfairly penalized, resulting in the loss of my fidelity bond for posting an offer. So far, this has cost me around 30,000 sats.

Here are the offer settings I used:

Public duration set to 23:59

Escrow/Invoice time set to 8:00

These settings should ideally allow you to sleep without risking your bond. If someone accepts your order right after you've gone to bed, the 8-hour escrow time should give you enough buffer to wake up, pay the invoice, and complete the trade.

The issue is that if someone takes your offer close to the end of the public duration—say, with only 1 or 2 hours left—the 8-hour escrow timer does not extend the overall duration of the offer. If you’ve gone to bed with less than 8 hours left on the public timer, you might have less than 8 hours to pay the escrow invoice before the offer expires and your bond is forfeited. This essentially penalizes users for not being able to respond instantly.

This setup seems flawed, as it forces users to stay vigilant during sleeping hours, risking money if they can't respond quickly enough.

I’m unsure if this issue varies by coordinator. Most recently, I noticed this with the Temple of Sats coordinator, but I believe I’ve had similar issues with others.

If this is the intended behavior, it raises concerns about potential bad actors using automation to take orders right before expiration, betting that the trade creators won’t respond in time—causing their bonds to be lost.

Has anyone else experienced this on Robosats? Any advice on managing it?

nostr:npub1v3tgrwwsv7c6xckyhm5dmluc05jxd4yeqhpxew87chn0kua0tjzqc6yvjh

That's not an intended behaviours. We tested setting a 20 min order + 8 hours scrow and it waited for the 8 hours

I'll check that on a test instance for a real 24h + 8 as your case.

Does it get solved eventually or it's an infinite loop?

Yeah I thought abiut that but didbt want to store all notifications to avoid duplications from other micro-apps, but a last 20 is fair enough 🙂 thanks!!

New Pokey release v0.0.6-alpha

Features

- Publish inbox relay lists

- You get a notification when your inbox list is too big

- Better relay authorization

https://github.com/KoalaSat/pokey/releases/tag/v0.0.6-alpha

I can't imagine an explanation for that, only thing I can say is that maybe the reply is not available on your inbox relays, and when you send a reply to it, your inbox relay tries to find the note in other relays and make it avaibake for you on that moment