Maybe robot A has a chicken and robot B wants it. But robot B has wheat and robot A wants that. If robot A and robot B can trade with one another right then and there, great, but what if robot A doesn't want wheat *right now*? He won't trade. And maybe when he *does* want wheat, robot B won't want a chicken anymore. With money (i.e. bitcoin) that both robots accept for all goods, robot B can trade *money* for the chicken and robot A can *save* it, and when he wants wheat later he knows robot B wants money (because you can buy *anything* with it) so he has confidence he can buy the wheat with it. 

 yes, let them hear me croon! 

 not yet afaik, that's an nsecbunker feature though. I would love to see support for that added to, including in more clients. I should be able to give a website on the desktop my public key and when it wants me to sign a message with my *private* key, it asks the client I use on my phone, which then prompts me to approve the signature request. In the background the two devices can talk over nostr to share the signature requests and signature approvals and such. 

 I don't know what you featureset is so it's hard to say

I suspect if more services add support for login-via-dm then it will be easier to add sign-via-dm next, send then I can just use one client to interact with all supporting services. Sign-via-dm also needs clients to support it though. But I nag client devs and server devs equally so let's get to it! 

 Thank you https://x.com/PlebLab for producing! 

 I reached out to them about fixing their login issues (they only support nip07 login which I don't like) so we'll see what happens. If they add login-via-DM, I will upload my music there.

njump.me/nevent1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg7waehxw309ahx7um5wgkhqatz9emk2mrvdaexgetj9ehx2ap0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq3yamnwvaz7tmwdaehgun4v5hxxmmd9uq32amnwvaz7tmwdaehgu3wdau8gu3wv3jhvtcpzpmhxue69uhkummnw3ezumt0d5hszrnhwden5te0dehhxtnvdakz7qg4waehxw309aex2mrp0yhxummnw3ezucn89uqzqq9es2p9nmunmqu4aggmynwdfgnyc6d2ukzl5pw9k576pstt39tgz55w8r 

 yeah but I want to use this opportunity to help curb the spread of the nip07-only virus 

 I'm glad nip07 is available for those who like it

the curse is the "only" part 

 (1) It doesn't work well on mobile

(2) I already have my private key in an app that supports DMs, so if I can log in with that, I'd rather not put my private key in another app

(3) your tool looks very neat, good job! 

 it's good. It is also an available login method in the library I linked in my feature request for wavlake 

 If you found a false statement, please point it out 

 I have a way to manually identify yourself as a decoy but I haven't automated that yet. What I want to do is use known "view keys" to identify decoys, because if you have the view key you know the "true" tx in which you spent your own coin, do if you've been used as a decoy you can automatically filter that out.

Right now it uses two heuristics: merge analysis and recency bias. If you received coins in two very close blocks and then spend them together, your ring, which should contain keys from random blocks, will have two suspiciously close blocks where you held both inputs. So you can identify those as the real spender's coins.

Recency bias takes advantage of the fact that most decoy selection algorithms are biased toward selecting keys from recently created utxos. Ones that are significantly older stick out like a sore thumb.

Other metrics I want to add include bot detection (which is based on identifying txs with many outputs, since these tend to be created by automated software rather than a real person) and taint tree analysis (which creates trees of possible senders fanning out backward in time from a known destination). 

 Which claim doesn't match? A lot of people seem to be assuming, wrongly, that this is a *fully automated* tracing tool. It's not. Most of it is manual. 

 they always have been

but it seems to take a considerable amount of manual work

I only have two automated heuristics right now and they only identify the sender in about 1 in 15 cases

I plan to add about four more automated heuristics but I still think you'll need a considerable amount of off chain data entry to get really good data 

 Then help me fix it please

I'd like it to be up to par with the ciphertrace tool that inspired me

I'm sure they have a lot more data to work with but I suspect you can get pretty far with on chain heuristics and maybe it's not that hard to source whatever off chain data ciphertrace is using 

 I replied to your comment, looks like you misunderstand how monero works. You said stealth addresses are used once and never seen again but in reality they appear on the blockchain multiple times: when the recipient receives money, when he or she spends that money, and possibly multiple other times as decoys 

 Someone challenged me to trace his transaction to its source yesterday on Bawdy Anarchist's twitter space and I denied the ability to do so. I want to build more automatic decoy eliminators because without them you need lots of off chain data that I don't know how to get or that is expensive to acquire. I am not sure how far you can get using only chain heuristics to identify the true spender; I suspect it's higher than 1 in 15 but lower than 100%.

One monero dev offered a helpful cli tool that detects all instances when a stealth address has appeared in a ring; this is something my tool is currently missing and would greatly help with building taint trees. I hope that through community effort my tool continues to improve in effectivelness. The bad guys shouldn't be the only ones with a tool like this, and before yesterday only ciphertrace had a tool like this (that I know of anyway) 

 > in the context of a cryptocurrency a "transaction tracing tool" would be able to identify the source, destination and amount of transactions

I don't think it has to automatically do that. A tracing tool is good if it helps automate some parts of the tracing task even if other parts remain manual.

> random chance identifies the sender in "about 1 of 15 cases"

But random guessing uses no data. This tool uses *data* to identify the sender. A random guess would not be grounds for doing anything. A statistical analysis is worth a lot more.

> the recipient that is published on-chain is a one time stealth address. not useful for tracing since SAs break the transaction graph.

They do not break the transaction graph. Stealth addresses do not appear just once, they appear again whenever the recipient spends his money and possibly in other transactions as decoys. Filtering out the decoys leaves you with only the true spend tx. You can do that *because* there is a tx graph that stealth addresses appear multiple times in.

> and amounts remain opaque

Except part of the amount is visible (the fee) and gives you info about the amount in the outputs as well as in the inputs

> additionally, if it takes "a considerable amount of off-chain information" to *actually use* NOBODY is tracing monero transactions

Seems like you contradict yourself here. First you say "nobody" and argue that the data doesn't exist, then you admit some people might do it and governments might have that data.

Not a good look. 

 >  it's impossible to know which is the true spend

Not impossible. My tool *automatically* detects the true spend 1 in 15 times. Better tools (like ciphertrace's) do better.

Lightning is superior. 

 thank you, that (final paragraph) is excellent feedback and a very good idea 

 "they are traceable" and "I personally have the resources to trace them" are different things 

 My monero tracing tool automatically identifies the sender of this transaction: c97d96fe61b2aee18a04fdb0975594c7e6d3334036e0e57e70666b9e5fe309b3

Try it here: https://supertestnet.github.io/examiner/

It seems to only be able to identify the sender in about 1 out of 15 transactions, but that's not nothing. I suspect tools with more data (like Ciphertrace's monero tracing tool, linked on my examinr github repo) do a better job of this, but it's silly to claim monero can't be traced in the face of two tools that at least sometimes trace it 

 > You didn't trace anything

I did. I identified this pubkey as the sender: 23396ea4b0ab93e3417c3650d47b1c8414bb593d7fc9cdb1b27244e139645302

The rest are the decoys. My tool uses on-chain data and two heuristics to identify the true spend. The two heuristics are explained on my github:

https://github.com/supertestnet/examiner/

Someone told you monero can't be traced by they were wrong. Ciphertrace has a tool for tracing them and now I've released a free and open source alternative. 

 Not yet. Want to try it with me today? 

 Yes 

 One of my projects was featured on SNL this week. It was a good week!
nostr:nevent1qqsrjqqxn93x0xtjguqz5hz0wy6sxef09e992zh0xleaauulngr7jygpzfmhxue69uhkummnw3e82efwvdhk6tczyzl9klqqk9jnpftfcap88rxnu6e8gta4sdq3pc5y8vsz8wpppnlgwqcyqqqqqqgyawtqy 

 He also informed me that this exists: https://news.bitcoin.com/ciphertrace-enhanced-monero-tracing-capabilities-governments/

So when people ask me "Then why does chainalysis have an LN risk assessment tool?" I can answer "For the same reason ciphertrace has one for monero: because exchanges will pay for it even if it doesn't work well" 

 It doesn't sound *that* hard to replace. I think fee credits are just a service agreement where Acinq holds custody of your sats until you accumulate enough to do a base layer transaction to open a new channel or enlarge an existing one. You could probably use ecash mints as a drop-in replacement: accumulate sats on an ecash mint until the user has enough to open or enlarge a channel, then do so. 

 he also says they *do* have a probabilistic tool

but you do you

have fun staying public! I really hope you enjoy your transparency chain

meanwhile I'll keep using lightning where we *don't* publish every single one of our transactions for every to analyze 

 I offer a nostr workshop where you build your own nostr client. It includes a segment where you configure your new self-made client to send/receive money using NWC and zaps. The workshop was recorded and you can purchase a copy here: https://supertestnet.org/workshops.html?option=nostr 

 robosats shows us the way

let's make more stuff like robosats and obsolete the government's fakenet 

 If you think I've said something wrong please point out the error. I'm using the term DNM as a standard term for a marketplace hosted on tor et. al. That's what robosats is. Just because it's a niche market (a market for money) doesn't make it not a market. 

 maybe instead of whining all day about how your competitors "don't count" you could step up your game and build something that competes 

 There is evidence that usage of robosats is on the rise: https://supertestnet.github.io/robostats/

It does millions of dollars in volume per year BUT that is still small relative to its bigger DNM competitors

It also has a better user experience than it's competitors so I hope it keeps growing and eventually dominates that part of the economy 

 instead of having one dude run the backend there are now four people running it and users have to pick which one they want to use in their trades. So the *total* amount of custodied btc is split up among four people, which is a bit like a federation if you squint. They call it the federated model. 

 True. I will try to remember to call out this incorrect nomenclature in the future 

 Yeah but he probably shouldn't

Having multiple people run the backend independently is a good way of distributing risk but it's not right to call that a federation

They don't "co own" a single robosats "address" like a federation would. They are all independent

Would be interesting if they all ran a fed instance though and custodied all the bitcoins there, then they could truly call it a federation

But I think I prefer the current model 

 Fedi* not fed 

 someone took my workshop! :D 

 #2​ is completely true. Monero users publish the recipient's stealth address in every transaction, in plain text. The money *ends up* in a different address (one that is *derived from* the stealth address), but you still publish an address belonging to your recipient, in plain text, in every transaction. And that's just a stupid thing to do. Use payment channels, bro.
https://image.nostr.build/b19eb779ec777f0ec8bae53c55c679e0bcaa5a49cf1fa194c42888f12873d84e.jpgobuserd 

 It relates to the recipient. He alone has the private key. And it will show up on the blockchain again as a possible sender if he ever decides to send the money to someone. This is not deceptive; it is the truth about monero's transparent blockchain. 

 It is not disingenuous. The recipient alone has the private key; it's his address, whose else would it be? Point 2 is the honest truth: the sender puts the recipient's address in plaintext on the blockchain and if the recipient ever decides to send it he has to identify it on the blockchain again as a possible sender 

 > Money must not have a destination

Monero, however, does. Bitcoin does too but at least with bitcoin you can prevent the sender from knowing where the money went. 

 > Monero's privacy is better than Bitcoin 

Wishful thinking won't mask your transactions, friend. Someone convinced you that publishing all of your transactions on a permanent blockchain is good for your privacy when it obviously isn't. Bitcoin leapfrogged way past monero six years ago when we created a payment channel network and stopped broadcasting all of our activity for the whole world to see. Catch up. Use lightning. Stop listing the sender, the recipient, and partial amount info in every transaction. Drop monero. 

 The block explorers are the whole problem bro. That's why we got rid of them. Learn the lesson. If you've got a block explorer, you've got a very serious privacy problem. 

 Lightning doesn't have terrible receiver privacy despite false claims to the contrary. Bolt11 "invoices" had terrible privacy by default, but you could (1) manually wrap them (2) manually replace your key with an ephemeral one (3) use keysend instead. Keysend payments never exposed the recipient, but they also didn't give the sender a "proof of payment." Now we have bolt12 as an arising standard that *also* doesn't expose the recipient by default, and *does* give the sender a proof of payment.

Also: the recipient's ip address is not exposed by default. You have to manually configure your network to do port forwarding if you want to show up as a routing node, and that is a big reason why most lightning users do not route payments. And most users who *do* route payments opt to do it over tor so that they *don't* expose their ip address. 

 Routing nodes do not know what amount is being transmitted. They only know the amount *they've* been asked to forward, they have no idea if that's the full amount.

I don't know what persuaded monero guys that publishing their transactions is good for their privacy but it's an obvious problem that bitcoin fixes. 

 True, but the lightning network does not have a block explorer, so I recommend using that instead 

 Oh yeah and with monero, every transaction publishes a list including the sender, the recipient, and partial amount info (specifically, the fee paid). It's on every monero block explorer, go take a look. 

 > Bitcoin got rid of block explorers?

Yes, we use lightning now. You should try it! Freedom from block explorers, dude! It's an amazing thing 

 > you're claiming there's some determalistic (or even some general probabilist method) that undermines monero privacy?

I'm not claiming that. But I think that's what this privacy expert claims: https://www.youtube.com/watch?v=9s3EbSKDA3o

> so what's your fucking problem?

My problem is that monero people claim it is private while permanently publishing massive amounts of info about each of their transactions -- something lightning fixes, even though a few monero influencers like to ignore that. 

 The wallet alone can spend from it. It's the wallet's address and no one else's. 

 Meanwhile, in monero, the amount is encrypted but the fee isn't

Also, the sender publishes the recipient's address and the change address in plaintext

And he publishes a list of possible senders and a public proof that he is one of them https://image.nostr.build/7abb9c125fd8f3f3c0680de658285831f42272bd33195f72af1bfe4770b6e1e5.jpg 

 "why are you lying to people?"

I'm not. The recipient's address is a key that you publish in plaintext, unencrypted, in every transaction. Why? Why not use the lightning network and avoid publishing the destination at all?

"yeah, that's how ring sigs work"

Do better: use payment channels and *don't* tell the whole world forever a list of possible senders with a public proof of your membership in that set. Again, you're not identifying a lie, just because you don't like the truth doesn't make it a lie. Lightning beats the pants off the outdated "privacy" tech used in monero. Get up to speed with the rest of us.

"what is the problem with knowing the fee?"

It is information about the amount sent, that's what. In lightning, we conceal that. In monero, you publish it. Catch up. Stop hurting your own privacy. Drop monero and use lightning. 

 If so, please deposit it in your nearest waste bin, the natural home of larper wannab altcoins like monero 

 - Learn how to write your first application using the nostr message protocol

- Connect your app to a bitcoin wallet using Nostr Wallet Connect to send and receive money

- Programmatically zap your friends and followers and receive money to any lightning address 

 I stand corrected. There is a free option here that I didn't see: https://proton.me/mail/pricing 

 thank you, I did not see the free account option 

 Your link says: "Bitcoin is not available as a payment method during account sign-up" 

 all the testnets are super to me 

 Yeah but I also posted this message on x so we good fam 

 correct, there is no such thing as change outputs. But if we create standard denominations (1k, 5, 10k, 20k, etc.) then we could treat them like dollar bills. If I owe you 50k, I could give you 3 20k utxos and you could give me back a 10k utxo if you already have one 

 > This would have to be used for higher amounts correct?

Since the last holder of the coins has to create one or possibly two base layer transactions to withdraw them, I don't think it makes much sense to create statechain utxos with a value lower than the cost of two transaction fees. And let's suppose transaction fees are $5 apiece. You might think "ok then the minimum value of a statechain utxo should be $10." But that would mean half the utxo gets consumed as fees (assuming a cooperative withdrawal) or up to the entire thing (if he has to do a unilateral withdrawal). If you want to keep 99% of your money (or 98% in case of a unilateral withdrawal) then the minimum reasonable size of a statechain utxo is $500, that way you'll still have $495 in case of a cooperative withdrawal (99% of $500) or $490 in case of a unilateral withdrawal (98% of $500).

> I would not think you can make payments for 5 dollar values then right?

Under these assumptions, that sounds like a reasonable conclusion. Of course, right now, transaction fees are only like 50 cents or less, so utxos as small as $50 make good economic sense for now. 

 > Does it have a proof of reserves (or proof of liabilities?) scheme to verify the funds of the mint?

Yes, it's already built into the client. For each of your statehain utxos you can click "show info" and it will show you what bitcoin address those coins are located in, which you can verify by looking up that address on your node or on a block explorer. No rehypothecation -- you hold a key to that address, and you hold a "backout transaction" which you can broadcast after a timelock if the mint goes down. (You can see the mint's signature for this transaction in "show info" as well.)

> can this scheme be rolled everyday instead of every 30 days?

You can roll it every second if you want to. You yourself audit your own coins as often as you want. 

 To make this easier, today I added a "Proof of Liabilities" button which only shows you information pertinent to proving that (1) an address on bitcoin has enough money to pay you your liabilities (2) you have a key in that address (3) you have enough signatures from the operator to let you withdraw your money unilaterally after a timelock

These items are sufficient to prove that the reserves exist and that the liabilities toward you exist...but they do not prove you will actually be paid, because a malicious operator could steal the money from the proof_of_reserves address with help from a prior holder of your statecoin 

 Very. There is a small amount of coding but it is all copy/pasting from a slideshow I created, and all the code is explained as we go 

 thank you!