31 sats \ 0 replies \ @supertestnet 24 Nov \ on: Central Bank of Argentina says it is not possible to close it bitcoin
I think that says closing the bank is non negotiable
Not an impossibility but rather a priority
And the statement came from the office of the president, not from the bank
Lnurl can also be provided by self custodial wallets
And if someone does like it, why should they change their mind?
Imo they should change their mind because blocking service to people from e.g. China or Iraq hurts millions of innocent people
It's bad
I like doing things without soft forks too
but if a soft fork improves the things then I'm in favor
I like things to be better, not worse
for example: "barely-working covenants via bitvm" is better than "no covenants at all"
but "fully functional covenants via a soft fork" sounds even better to me
a similar consideration applies to sidechains via bip300
if they are better than what I can make with bitvm then I want the better thing -- but I am also happy to do a barely-functional version with bitvm, because "something" is better than "nothing"
bip300 is better than bitvm imo
it is safer and the way to build a sidechain with it is already clear, unlike with bitvm, where I for one am still theorizing
based on the presenter's information I don't think the amount of remixes matters. Suppose a coin is mined directly into a coinjoin and spends its entire history in mixes and remixes with 30 participants apiece, except when it's held by an exchange. Suppose you buy it from kraken and do 2 remixes (in coinjoin 382 and coinjoin 4773) before sending it to bitrefill.
In such a case, bitrefill can still see kraken in its taint tree, because they can see (1) it came to them in coinjoin 4773 which had 30 possible "inputs i.e. senders (2) one of which was an "output" from coinjoin 382 which also had 30 possible "inputs" i.e. senders (3) one of which was from someone who got the coins from kraken. So it had at least 60 possible senders, 1 of which was kraken. Therefore kraken is in its taint tree.
If you send coins to bitrefill repeatedly and kraken always appears in all of your taint trees, then even if you do 2 remixes, 10 remixes, or 1000 remixes, bitrefill can conclusively infer you must be a customer of kraken, because it is statistically impossible for kraken to show up in all of your taint trees unless that is where you get your coins.
the guy in the video is the attacker (in my imaginary scenario)
yes, and a single essay can't cover all the bases. I recommend looking up how tor works in particular if further information is desired.
Teleports aka coinswaps do help and I have my own implementation of them here: https://github.com/supertestnet/utxo-dealership/
They let you "sell" your taint tree to someone else (and buy theirs) in a way that can't be easily identified on the blockchain. If you do coinswaps frequently, you make the overseer attack, in particular, much harder to do, because the taint tree they are analyzing is the wrong taint tree. Taint tree analysis relies on users engaging in repetitive behavior, but with coin swaps you "purchase" someone else's repetitive behavior, disrupting the analysis.
Nice job! I love sea shanties and bitcoin. BTC Minstrel made a playlist of his B-T-Sea Shanties here
I made a bitcoin sea shanty too
Your song is awesome btw! Just one criticism:
Try to buy the low, try to sell the peak
This seems like bad advice. Most people who try day trading lose their money. If I ever sing this I'll change that line to this:
Try to stack sats on a daily streak
Other than that, great job!
Players can prove to outside observers whenever the lottery coordinator cheats
Sounds like it can equally be called "provably unfair"
There's no such thing as free infrastructure is true of nostr or otherwise
Agreed
a nostr native solution is a 10x cost and friction reduction
I disagree, though I suspect the potential is there to make a 10x cost reduction on nostr
a few sats to a relay vs. several dollars for a web-server or custodian
yes, this is promising...but I don't think we are there yet due to market immaturity in nostr. E.g. it seems to me that relays often take the money and run, whereas web servers do that less often. The market seems to be on a path toward maturity though and I am hopeful
More problematically, the network friction is causing untold numbers to not use Lightning at all
Yes and this is true for nostr too
For now
correct, it is kinda like lightning:
- it is an off chain protocol
- it allows unlimited off-chain back and forth payments
- these payments are compatible with and routable through the real lightning network
it is also more scuffed:
- force closures are less efficient
- not everything is tested
- it doesn't have a built in p2p network so it's slower
- it doesn't use source routing so it's less private
it is true that's all nostr is (well, mostly...it also does some data caching), but there is a saying I try to keep to heart:
if you offer something free, people will take it
nostr relays cannot offer free bandwidth and storage forever because (1) those things cost money, which is a scarce resource (2) bots will consume all of the free bandwidth and storage you offer, and by extension they will consume all of the money it costs you to provide those things for free, until you run out of money, at which point you must cease operations
in order to survive and escape/avoid that doom loop, relay operators must ensure that their income exceeds the aggregate costs of bot activity on their relays
rate limits are one way to help with that. They help keep aggregate costs low and predictable
so by having them, "free relays" aren't "using it wrong," they are managing their costs, which is a precondition for sustainably offering a service for free. No service with unbounded costs and unreliable income can survive long, therefore rate limits are a survival mechanism
but it has consequences: stuff that needs to go beyond the standard rate limits (like the frightening network) cannot rely on free relays
users would need to register with a paid relay, and that sucks...or at least it feels like it right now. I have a feeling though that paid relays are actually a good thing, and are the very thing that will ensure nostr's success in the long term
there is a version of the frightening network here that uses nostr for message transport
but it sucks
nostr relays typically rate limit you to about 6 messages per 5 minute period
but on the frightening network you send your peer about 12 messages interactively, all within a few seconds, in order to do a state update
so nostr rate limits me and then there's a force close because your counterparty seems like he stopped responding mid-state-update
nostr seems to suck for this purpose
Ask me anything
I probably won't answer but asking is fun too
I think it should be from Zeus side to limit zaps over Zeus pay
The recipient does not know who the sender was, so it is much harder to implement censorship on the recipient's side
not Mutiny limiting payments to Zeus LSP
Mutiny is the wallet that cannot safely pay hodl invoices. To me, the responsibility to "do something" about it is on them, and disabling payments at least until a long term solution is available <-- that is, imo, a perfectly reasonable step to take. Otherwise their users lose funds.
I consider this a dangerous precedent from Mutiny side
I think it is smart at least as a short term solution. If a way to make these payments safe on mobile is thought of then I will support them re-enabling them by default. But right now it isn't safe. Disabling something unsafe -- by default, with an option to change it for those who know the risks -- seems like a good precedent to me.
I support Mutiny's censorship because it is a sensible default behavior for a mobile node which users can change if they don't like it. It is worth noting that once you define censorship as "auto-failing some payments" (which I think is a perfectly fine definition btw) then all lightning nodes perform some censorship.
LND autofails (censors) payments to yourself by default, but users can configure it to allow them. CLN autofails opening a second channel to the same destination by default, but users can configure it to allow it. Now Mutiny node autofails payments to a known source of hodl invoices by default, but once again, users can change it if they want to.
Setting reasonable defaults for users is good and necessary. I am glad Mutiny makes it something you can change if you don't like their default. They are trying to give users a default setting that doesn't result in a lot of force closures on mobile. That is smart. Good on them.
Maybe someday mobile nodes will be able to safely make async payments. When that happens, I hope they will allow them by default. But today is not that day -- async payments are not spec conformant right now and for mobile nodes they are dangerous. I for one applaud Mutiny for finding a reasonable solution in the interim. And I for one want to work on a better solution for the long term.