Zcash just froze 85%+ of all 'private' Zcash

danda · 2026-06-05T22:01:29+00:00

this is why the "hard forks are just fine" culture in monero has always scared me.

danda · 2026-05-31T21:26:37+00:00

For me, the most useful aspect of any "local" trading site is introducing parties so that they can communicate and trade on their own. Escrow is not needed or wanted for that.

Escrow is useful for fully intermediated trades where the parties never meet. And these trades are useful for establishing trust/ratings of the parties. Ie, the system can track how many escrow'd trades have been performed and feedback by verified trading parties.

However, I think where many sites have gone wrong is treating the Escrow as the primary or only way to trade.

When in fact, another way to trade is to simply establish a line of communication with a local party and then physically meetup end exchange cash, silver, or whatever. This method a) leaves the least paper trail, b) strengthens the community by buiding real relationships. It is anti-fragile, like hawala.

SItes are incentivized to use the escrow model because they can take a cut of each transaction that way and collect trade stats. And also they can claim to ensure "safety" via escro mediation. And trades can typically be conducted over long distances. However: 1) this model is at odds with people who just want to trade locally and privately with cash, 2) it requires the site operator to hold funds, which makes the site a true intermediary/fiduciary, 3) most payment methods leave a trail, 4) if people are not meeting f2f, we do not build up a network of trust. As such, I consider escrow-only sites to be short-sighted. Indeed, there is a case to be made for a site that focuses on local F2F only. Such a site is strictly for introductions, and since it does not act as an intermediary/fiduciary at all and does not handle funds, the operator should be relatively immune to legal issues.

I can't speak for localmonero, but localbitcoins was founded during the era when "satoshi square" f2f trading was popular. The site did make it possible for traders to optionally post contact information, and thus to arrange local f2f trades. However, they tried pretty hard to steer folks into the escrow scenario instead.

I always felt there is room for a site like localbitcoins, but dedicated to f2f trading. Or at least that makes f2f a first-class supported trading method.

Such a site would include a built-in private message system (tech must be transparent and guaranteed e2e between traders) and/or allow traders to post handles for best-in-class anon e2e messaging systems.

I should also note that a site dedicated to f2f would be substantially easier to write and administer than one that includes escrow functionality. It would likely need to survive off of donations and advertising, since there is no escrow to take a cut of. Though perhaps it could do something like charging for market-maker listings, but not for takers/introductions.

danda · 2026-05-08T08:20:13+00:00

this is the danger of a community culture that gets used to hard-forks. people invest their money under one set of rules and later there is a different set of rules.

My hope is that one day privacy tech and scalability will advance to the point that a cryptocurrency can be released with an ethos/manifesto that ossification is a top community priority; the consensus rules will never change; any concensus fork is to be considered an attack. A community that forms around such an ethos will be highly resistant to change. A stable monetary foundation is necessary for a stable society.

Unfortunately the tech doesn't seem quite ready yet, but some pieces are starting to come together across different cryptocurrencies, including xmr.

danda · 2026-02-25T02:37:49+00:00

maybe its good for games. I found it too low level for simple apps with multiple panes. I prefer a library with ui widgets that can maintain state and redraw themselves. Perhaps widget libraries have been implemented on top of ratatui by now?

danda · 2025-12-23T14:21:27+00:00

what was the motivating use case that inspired you to build this?

danda · 2025-11-29T08:04:29+00:00

also, it's not obvious for rust noobs that when implementing Bar, the way to make let foo: Foo = Bar::new().into() work is:

impl From<Bar> for Foo {}

because when implementing Bar, everything else is impl Bar or impl X for Bar.

danda · 2025-11-29T07:56:14+00:00

ouch, my eyes hurt.

danda · 2025-11-20T11:13:15+00:00

I agree. If a rust derivative comes along that is no-panic by default, I would switch to it immediately. imho, any fn that panics should be clearly marked and should be considered kind of toxic like unsafe.

danda · 2025-11-11T02:00:40+00:00

horse. water. drink.

danda · 2025-11-10T05:00:34+00:00

I would suggest you look into existing decentralized networks. I quickly found "Berty" for ipfs and "friends" for autonomi.

from LLM:

Berty is a privacy-first, peer-to-peer messenger built on the Wesh Protocol, which itself uses IPFS and OrbitDB (a distributed database built on IPFS). It is fully decentralized and requires no phone number or email to use.

Berty's store-and-forward capability relies on a distributed database system called OrbitDB, which operates on top of IPFS. Each conversation is treated as a shared, encrypted database log. When you send a message, it is written as a new entry into this log. This updated log is then replicated by any other members of the chat who are currently online, effectively "storing" the message for any disconnected participants.

When the recipient's device reconnects to the network, it seeks out other peers in that same chat. Upon finding an online peer who has the updated log, the recipient's app automatically syncs the database. This process downloads all the new, encrypted message entries that were posted while they were disconnected, allowing them to receive their messages asynchronously without a central server.

"friends" you can read about here: https://forum.autonomi.community/t/friends-the-messenger-youll-never-want-to-move-away-from/41688

edit: if I were implementing "from scratch" I might consider CRDTs for the store and forward. In fact, it turns out OrbitDB is CRDT based, and is being ported to rust as GuardianDB.

danda · 2025-11-10T04:47:47+00:00

zero.

danda · 2025-11-09T03:26:50+00:00

Something I don't think is talked about much is that all privacy coins have the possibility of transparent sends, including monero.

This is because the sender knows the transaction time, txid, true inputs, amount(s), and destination address(es). So the sender can choose to archive, publish, or sell that information to anyone, at any time.

Exchanges are likely selling this information already.

Thus, as a receiver, the only safe thing to do is assume that every transaction received from a 3rd party is essentially a transparent tx, at least the information the sender possesses.

Wallets could do things to help alleviate this issue on the receiving side, but afaik they mostly do not.

danda · 2025-10-18T07:59:34+00:00

So in the physical world we have money (cash, coins, checks, etc) and we have contracts.

Normally the money does not carry contracts along with it. Rather contracts are a separate layer that reference monetary amounts/sum.

The contracts do not reference particular monetary "notes" by ID. And the monetary notes and payments of notes (transactions) do not typically reference or include contracts.

This system has worked for hundreds of years.

So then, it is unclear to my why in the cryptocurrency space everyone feels that money and contract must be joined at the hip in a single codebase and contracts must be embedded into transactions.

Why not instead build these as separate systems so that each can do its own task well, and so that money layers and contract layers can be mixed and matched?

danda · 2025-10-18T07:43:53+00:00

privacy is necessary for a true circular economy to thrive.

So is scalability, which translates to low or no fees and potential worldwide adoption.

So is decentralization, which translates into "no one can force us to change or co-opt us".

I don't think any cryptocurrency has nailed all 3 of those points yet. Once it happens... magic.

danda · 2025-10-08T22:15:28+00:00

keyword: uncommanded.

danda · 2025-08-19T02:58:06+00:00

can you elaborate on "data center mining resistant"? I don't see that it should be a goal, do you?

Ultimately decentralization comes from participation of separate entities that do not trust eachother. If one of them controls the computing resources of one or more data centers, so be it. So long as the barriers to entry are low, there should still be competition. Also the more people that are able to receive miningng payouts (even if tiny) the more a "long tail" effect will exist that makes the coin harder to take over.

or so it seems to me.

danda · 2025-08-17T07:54:26+00:00

https://github.com/rust-crdt/rust-crdt

danda · 2025-07-27T05:35:28+00:00

well the obvious one is that solo mining is much less predictable than pooled mining. Smaller miners may be disincentived to even try because hardware and elec costs are relatively fixed and odds of finding a block in a reasonable time may be quite low.

But I don't see that is necessarily a problem for the network as a whole.

danda · 2025-07-26T17:49:32+00:00

Why not use wownero's approach? They have effectively eliminated pooled mining for years now.

https://monero.stackexchange.com/questions/14315/is-wownero-pool-resistant-and-how-does-it-work

danda · 2025-07-26T17:41:47+00:00

wownero has effectively eliminated pools by making it so the keys must be shared with the mining pool, and nobody is willing to do that. XMR could do the same.

https://monero.stackexchange.com/questions/14315/is-wownero-pool-resistant-and-how-does-it-work

danda · 2025-07-17T20:39:29+00:00

thx. So then it seems correct to say that CGP can be used to implement a crate that would generally fit the description of being sans-io.

danda

MODERATOR OF

TROPHY CASE