pull down to refresh
100 sats \ 0 replies \ @conduition OP 20 Jul \ on: PSA: i got shotgun-KYC scammed by PayWithMoon.com, lost $1000 bitcoin
Hey stackers, posting to update anyone reading this 5+ days later. My money is still locked in moon sadly. I have received no reply from their team or CEO.
NYKNYC rings truer every day.
First, let me apologize on behalf of bitcoiners everywhere for your IRL frustrations, and for the terrible advice given by my peers in other comments here. Bitcoiners can be a bit dramatic at times, and sometimes feel so righteously invigorated by their beliefs that they forget they can be wrong and do wrong.
You've done nothing unreasonable here. Maybe you should've had a talk with your hubby earlier, but you didn't, and eventually temper got the better of you. It's OK, it happens to us all sometimes.
The important thing is that you and he have a frank and honest discussion once both of you have calmed down. If the snap was on 4th of July, i'd say you're overdue for a good sit-down chat, assuming you otherwise haven't talked about it yet. I think both of you have reason to apologize.
I can't give you the "magic words" because after 9 years' marriage, you likely know him better than anyone else, including anyone on this website or anyone on his podcast.
My only advice is: When/if he asks you why you don't want to listen to his podcast, don't let him press you for constructive criticism - it may not end well. Just say "it's not my thing". Sounds like the podcast means a lot to him. He needs to understand that you support him and his podcasting in a way that doesn't involve you listening to it.
Good luck!
Thanks for posting here. I replied to the email ticket with a detailed description of my coins' origin.
They came from my employer originally. I used them to buy XMR on an instant-exchange before depositing some of the BTC change into PayWithMoon, so maybe that's the cause of the flag. Chainalysis will sometimes flag coins even if they don't directly originate from a known "bad" source - One of their many flawed heuristics which lead to situations like this.
I appreciate that your business has to comply with KYC laws to keep the governement off your back. We can all agree KYC/AML sucks, and I can live with being denied access sometimes, but opaque rug-pulling isn't an acceptable solution. If your team had simply refunded my coins I would've had no cause to complain. Instead they stonewall me, effectively saying "Your money belongs to us now, unless you KYC."
It sucks that I have to complain publicly to get any recourse. I hope you can train your team to deal with these situations better, and I hope we can come to a resolution where I can get my money back without doxxing myself. Let's take the rest to email.
I helped Spark's devs design their protocol under contract. I can confirm OP's description is roughly accurate, although there's another layer of complexity on top of the basic statechains described here.
A statechain UTXO by itself is not super ergonomic because you have to transfer all of it or none of it. Spark wanted to design a system where you can subdivide statecoins up into smaller units using a tree of off-chain transactions, by sharding the keys that control the locked UTXO. More info here. The cryptography behind it is really cool, but not described very thoroughly in the docs. Maybe they're reworking the protocol since I left? IDK
Thanks! Check out the landing page of my website, https://conduition.io - I have my contact details posted there
ZK STARKs are very powerful and will certainly be useful for off-chain bitcoin smart contracts, rollups, etc, but STARKs are very complicated and inefficient.
An average bitcoin dev could probably implement almost any hash-based signature algorithm in a day or two. Contrastingly, implementing a STARK prover/verifier seems to demand teams of people with years of expert knowledge in the domain. Even established STARK software like Winterfell suffer from awful usability/ergonomics. Read their README and examples, and you'll see what I mean.
I don't think we should build on-chain bitcoin security standards based on such things without a simple easy-to-use library to depend on, like libsecp256k1 is today. Perhaps there will be a more stable and usable STARK library in the future but so far I haven't found any. The closest is RISC0, but AFAICT it's bugged for secp256k1 usage, and they're not fixing it.
@mega_dreamer is there anywhere I can contact you directly? I'd rather not broadcast details of my setup publicly
Thanks and good point. I'm new to this and wasn't expecting mercury to unilaterally publish without asking me first. My mistake was in not being explicit about timeline with them, and also Tom admitted that he thought my vulnerability report (given over a private link to my website) was publicly accessible on my blog (it wasn't). That's why mercury rushed to publish fixes ASAP.
Miscommunication all around and a good learning experience for next time in a low-stakes environment
Very nice work. Like some others have commented, I was unable to log in with lightning-supported browser extensions, so i had to use username/password. When I clicked on a market and tried to buy shares in an outcome, i received a small red popup which said "Prediction is not valid", and the market card was stuck in a "Please wait..." loading state. Trying again I got the same thing.
Bug reports aside, I'm obliged to remind viewers that this market is centralized. The Predyx operators seem to be the only entity who ultimately decides how to settle all predicted events, and deciding who gets paid. They also custody your money.
For now that's OK because there aren't many alternatives, but please be careful and be aware that decentralized options will exist in the future which let betters spread trust out among many oracles, without any custody risk.
Our first covenant-specic opcode proposal, OP_CheckTemplateVerify — or “CTV” as it’s commonly referred to — aims to create a very specific, restricted, covenant opcode by doing exactly one thing: hashing the spending transaction in a specified way that does not commit to the input UTXOs, and checking the resulting digest against the top stack element. This allows the spending transaction to be constrained in advance, without making true recursive covenant restrictions possible.
I had never really understood OP_CTV before reading this paragraph. Bravo
Certainly there is no publicly released client software configured for mainnet
The mercury client code can be configured to use mainnet statecoins by simply setting
network = "bitcoin" in the client's Settings.toml file, so it's not that hard to set up. In fact, to demonstrate the vulns to mercury I double-spent some mainnet coins after ostensibly "transferring" the statecoin UTXO to Tom. But it would take a conscious effort to do that, in spite of blatant warnings to the contrary.Really I have no idea if there are any mainnet users, but I find it unlikely. See tom's post below for more info
Well, due to the nature of mercury, it's impossible to know. The key server is a blind-signer which is agnostic to whether its users are on testnet, mainnet, signet, etc.
The vulns themselves are in the client code, and mercury has no insight as to who (if anyone) is running that code, or what networks they're running on. No way to notify them besides publishing.
xD no no no, @tptrevethan and I had a very reasonable discussion of how to handle this and roll out fixes. I offered to give Mercury as much time as they needed to roll out fixes, but then Mercury went ahead and published the vulnerability report on Twitter. Only after seeing that did I publish it to my blog as well. The cat was already out of the bag at that point.
Also see the twitter thread here: https://x.com/TTrevethan/status/1832064237499269463
The vulnerabilities are described in detail in my blog here: https://conduition.io/code/mercury-disclosure/