pull down to refresh
@supertestnet
stacking since: #96
3 sats \ 9 replies \ @supertestnet OP 15 Jan \ parent \ on: I keep receiving cowboy credits. I do not want them. How do I turn them off? bitcoin
Well I hope you let me know when it's an option
Voting with your feet is sometimes the only recourse you have
Why should I continue to drink a wine that turned sour?
Do you have attached wallet?
Yes
There's no way to refuse CCs
Why not? Why force them upon us? Why not let us choose to always reject them, and if a user has chosen that, just show the sender an error?
There could be the possibility to forwarding CCs to the daily rewards.
That seems far worse than just making them optional for those who don't want them. I don't want someone else to receive these credits for me. I want the sender to be unable to send them to me.
There’s no way to do this automatically
Will you add a way to do this automatically? Not "make it so I can automatically donate them" but rather "make it so I can turn on an option that never lets people send them to me in the first place"
Your tool doesn't "automatically eliminates every decoy spender and heuristically identifies the real spender". It's all manual guessing.
It's not all manual guessing, it automatically applies heuristics when possible. You can see an example in this video:
Note that I don't manually guess anything. I simply pick a transaction from a recent block and it automatically identifies the decoys: namely, every Possible Spender except #1 is (according to the automatically-applied heuristics) a decoy. #1 is the "real" spender.
The heuristic applied in that case is called Recency Bias and is discussed as a standard characteristic of monero's decoy selection algorithm in the excellent Breaking Monero series (see Episode 5).
The recency bias heuristic takes advantage of the fact that the decoy selection algorithm used in the most popular monero wallets is biased toward selecting keys from recently created txos (on the principle that actively circulating coins are more likely to be spent than old ones). When you have a group of "new coin" decoys, coins that are significantly older stick out like a sore thumb, and you can plausibly identify them as the real spender's coins.
Consequently, I didn't need to manually eliminate the decoys; my software simply noticed that every decoy in the example transaction was a recently-created txo, but there was one txo that was much older. That one stuck out and, per this heuristic, was the real spender, because it is very unlikely that the decoy selection algorithm would choose that txo.
Reviewing your script, I think it has two problems:
(1) it appears like the 3 of 5 option has to wait a year. Based on your description, I don't think that's what you want. You said, "You can spend money at any time with 3 of 5." But the script for the 3 of 5 has a 1 year timelock just like the one for the non-3-of-5.
(2) It appears like the 2-of-5 script and the 1-of-5 script are currently encumbered by an identical timelock. Which means the 1-of-5 person can take the money after waiting only 1 year. Based on your description, I don't think that's what you want. You said, "after another 52596 blocks, the multi-sig reverts to 1 of 5," and I think by "another 52596 blocks" you mean "an additional 52596 blocks."
To fix these issues, you could rewrite the script like this:
IF
//this branch requires no timelock at all, so the 3 of 5 can spend at any time
3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5 OP_CHECKMULTISIG
ELSE
//the following branches are encumbered by different timelocks
IF
//if you only have 2 keys out of 5, you have to wait 1 year
//but the 3 of 5 can renew the 1 year wait time by spending the money
//before the year is up using the branch above this one
<52596> OP_CHECKSEQUENCEVERIFY OP_DROP
2 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5 OP_CHECKMULTISIG
ELSE
//if you only have 1 key out of 5, you have to wait 2 years
//but the 3 of 5 can renew the 2 year wait time by spending the money
//before the 2 years are up using the first branch
//and the 2 of 5 can also renew the 2 year wait time by spending the money
//before the 2 years are up using the branch above this one
//though only after themselves waiting at least 1 year
<105192> OP_CHECKSEQUENCEVERIFY OP_DROP
1 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5 OP_CHECKMULTISIG
ENDIF
ENDIF
except indulgence letters are awesome
[the] indulgences [are] for those who practice corporal and spiritual works of mercy. The decree lists visiting prisoners, spending time with lonely elderly people, aiding the sick or disabled, and helping those who are in need as examples.
That's pretty cool, especially by comparison with "give $25 to some random website and now you can feel good about yourself -- oh, and you don't even get any time off in purgatory"
Those criminals were caught in your first link because of the fiat on/off ramps they were using
Link?
and feds in their groupchat
Source?
All it does is let's you see the Monero blockchain which you can already do with any Monero block explorer
It also does this: for about one in five transactions, it automatically eliminates every decoy spender and heuristically identifies the real spender. It does this by exploiting weaknesses in monero's decoy selection algorithm that are widely known in the monero ecosystem and actively being fixed, e.g. through FCMPs. I've never seen a monero block explorer do that.
vast majority are using custodians and LSPs
Do you have evidence of this?
which both diminish Lightnings privacy guarantees
They have tradeoffs. The custodian or LSP knows additional data about your transaction; everyone else knows less data. Some LN custodians and LSPs have really good privacy policies (e.g. most ecash mints) and that is possibly why some LN users prefer to use them rather than do all the work themselves.
Using a remote node on Monero, behind Tor/VPN, is much more accessible
And much less private. P2P traffic is not encrypted on monero so in addition to seeing all your transactions (which, in monero, expose a lot of your data), your peers also get extra data about where a transaction originated. Dandelion helps with this, but it's not foolproof. P2P traffic ought to be encrypted imo like it is on lightning, so that your peers cannot see whether the message you are sending is a transaction or a probe or something else. (You know, like we do in lightning.)
tell that to these guys: https://cointelegraph.com/news/monero-transactions-japanese-authorities-arrest-18-scammers
there is free and open source software for tracing monero transactions: https://github.com/supertestnet/examiner/
as well as paid commercial software: https://news.bitcoin.com/ciphertrace-enhanced-monero-tracing-capabilities-governments/
care to show me some tools for tracing lightning payments? it's much harder to do, since there's no blockchain to analyze where everyone publishes their transactions
to trace lightning you'd have to subpoena records from routing nodes with the following hurdles:
(1) you don't know which ones to subpoena, so you'd probably have to subpoena all of them
(2) most of them run on tor, meaning you don't know where to send the subpoena
(3) even if you get the subpoena to them, they might be in a jurisdiction where your subpoena has no authority -- so good luck getting a reply
it's pretty simple, really: with monero, you've got lots of data to analyze to find the sender; with lightning, you don't
here's a podcast where I go into more details about this: https://x.com/saucy_xmr/status/1842664585377010175
Yep. Well, I mean, there is a difference. Lightning certainly involves staking assets, but lightning nodes aren't network-level validators. They only validate to secure their own ability to unilateral exit, not to secure other people's money
It's possible to *have* stake without being a proof-of-stake *system*
I find it interesting that the lightning network uses an account model even though it is built on top of the utxo model
Each channel is just one utxo but it does not "act like" a utxo while the channel is open. Instead, like on ethereum, if you send someone money via lightning, your lightning channel just has less money in it now. Well, technically that money is still in there, but your "account" is just your "side" of the channel, and your money is not on that side anymore
It's neat that the utxo model is powerful enough to emulate the more familiar account model on a second layer
Good point. Doing so might allow you to fit another pubkey in the script, or maybe more than one, and make the n-of-n larger than a 67 of 67.
Alternative headline:
Stacker News launches its token!
Tokenomics:
- For now, Cowboy Credits are pegged to bitcoin at a rate of 100000000:1
- Cowboy Credits can be printed at any time by k00b if he decides to modify the peg ratio -- and he can also raise or lower their "official" price at will
- k00b retains the right to freeze, drain, or burn any community member's Cowboy Credits whenever he wants, for whatever reason he wants (or for no reason)
- There is no official place to "sell" Cowboy Credits, but if you do things k00b likes he might give you bitcoin
- You can send Cowboy Credits to any community member on stacker.news, so anyone can set up an exchange if they want to
- We'll see if the community creates exchanges so you can trade Cowboy Credits for other tokens
The launch is LIVE so you can buy Cowboy Credits right now at stacker.news/credits
You do not need a bank account to use robosats or bisq. Money orders and cash by mail are perfectly serviceable options and both let you use the service in volumes of tens of thousands of dollars per transaction with no risk of a closed bank account. There are other risks, though.
your Nazi analogy is lazy
That is a dumb criticism in my opinion.
A lazy analogy, I assume, is one that sprang to mind immediately, rather than taking a while to think of. Well, to be frank, I don't think that's a bad thing. After finding the analogy made the point I wanted (which is that no one should follow evil orders), it would be silly and pointless to say "oh, no, that was too fast. Let me spend extra time for no reason -- other than not being called lazy -- to come up with a different analogy that makes the same point." An analogy is critque-able based on its applicability, not based on how easy it was to think of.
and extreme
I'm glad this criticism has to do with my analogy's applicability. And I freely admit that nazis did something far worse than what KYC'd exchanges do. But I don't think that affects the analogy's applicability, because the analogy isn't about *how bad* the violation is; it's about *the rationalization* of the violation. It's about someone saying "Don't blame me! I was just following orders!" And that rationale excuses anything, including far worse things like nazism. It's a bad rationale so I criticized it by "reducing it to the absurd." There is nothing wrong with going to the extreme to win an argument if that's where your opponent's argument leads. And the "just following orders" rationale leads precisely there.
It means your clip is empty
No it doesn't. Analogies don't come with an expiration date. You may be tired of hearing people bring up nazis in argument; but just because it's been done does not mean it's bad to do. An argument does not become fallacious through frequent use so I recommend not dismissing an analogy just because you've heard it many times.
you have to understand that you are using a business that must suck whatever dick the government says
That is not true. Strike and Kraken can shut down their companies. Therefore they are under no obligation to comply with these evil laws.
If the nazi train guy said "you have to understand, I *had* to send them to Auschwitz, my only other option was to quit" -- I would say, "then you should have quit."
Compliance with evil laws is never acceptable, not even when the government says you'll lose your paycheck.
Once more people come I’ll come back
Liquidity providers might not be there because "no one's buying thousand-dollar amounts there." Place those offers, and keep them up, and liquidity providers will be attracted to the platform so they can fulfill them and earn money.
The liquidity on these services is terrible
That is why I keep trying to convince people to use them
The park will stay empty til people start playing there
When you notice there's no liquidity -- make an offer!
Imagine someone saying "I don't blame the nazi train guy, the regulations were very clear about what he had to do"
"The government told me to" is no excuse for violating your users' trust. A man of principle should shut down his company if his only other option is compliance with evil laws.