I forgot that twitter doesn't let non-members view threads anymore. So here are the details:
Even without bolt12, LN receiver privacy is better than monero in this respect:
In monero, the sender always knows the recipient's "real" address (the one on the blockchain) and can provably map it to their stealth address. But in lightning payments, the invoice has to tell you the pubkey of the *node* which received the payment (though you can spoof it), but that pubkey doesn't contain any money. It's like a stealth address in monero, except the sender *cannot* map it to the *real* address that received the money, or at least, not necessarily. There are *some* people who've managed to figure out the receiver's address on the blockchain just from their lightning invoice, but even that information is spoofable. In monero, it isn't. So even in this respect, LN > Monero.
Also, it is wonderful to hide your lightning node from the sender, and is similar to not showing your monero stealth address to the sender. But in monero, there's no tools for that. In lightning, blinded paths are becoming standard. So LN is way better.
Explanation here: https://x.com/super_testnet/status/1881453818413822457
true, I did not look at the website. I now understand your proposal better thanks to the post by nostr:npub1q6ya7kz84rfnw6yjmg5kyttuplwpauv43a9ug3cajztx4g0v48eqhtt3sh and I think it's a cool idea. Good luck!
I don't understand the project. Generically, it seems like they want to put the King James Bible on a nostr relay that they self-host. I don't see a problem with putting stuff on your own relay, though I do wish they used a *complete* 73-book bible like the Douay Rheims instead of the KJV, which, in most editions since the 1800s, only includes 66 books of the bible.
In a now-deleted post, F2Pool once admitted to running a "tx filtering patch." https://archive.ph/UFP8l It seems they are running it again. Anyone wanna calculate how much revenue their miners lost due to this censorship? A revenue-loss tracking website would be pretty cool.
https://b10c.me/observations/13-missing-sanctioned-transactions-2024-12/
I don't think it really needs to be a server. Lightning wallets only need to get online every 2 weeks or so to ensure their counterparty isn't cheating. I think a bitvm wallet could do the same thing. As an (occasional) bitvm dev, I want to ensure my bitvm programs use a 2 week timelock to give users time to (1) open their device and check that the program was executed correctly (2) and penalize their counterparty if they ran it wrong.
I think optimistic protocols are fine as long as you yourself can prevent fraud from happening against you by doing the verification yourself.
The lightning network is a good example of an optimistic protocol. My counterparty can *try* to broadcast a channel closure transaction containing old state, but I am optimistic that he won't, because whenever he broadcasts a transaction, *I* verify that it contains the current state, and if not, I take his money.
I think bitvm can be like that. Someone can *try* to finalize a bitvm contract without running the bitvm program correctly, but I am optimistic that he won't, because whenever he broadcasts a finalization transaction, *I* can verify that it produces the right result, and if not, I take his money.
This is an interesting article: https://dba.xyz/a-bitcoin-l2-thesis/
But I have two objections.
#1: the author accuses bitcoin of having a "lack of programmability." It doesn't. Bitcoin Script is computationally universal because it has all the logic gates, and the bitvm whitepaper proved that you can get around the script size constraints by transporting state from one transaction to the next. So bitcoin script is fully programmable: anything a real computer can do, bitcoin script can do. It just requires lots of transactions (i.e. it's expensive).
#2: the author ignores the lightning network on the grounds that he wants to "mostly focus on fully programmable L2s."
But the lightning network is just as programmable as bitcoin is. A lightning transaction is just a bitcoin transaction that you haven't broadcasted yet. So you can do just as much programming therein as you can do in a "regular" bitcoin transaction, and even create a bitvm-like chain of transactions executing a complex program, all built on a lightning transaction and therefore on a layer 2.
I want to see work done in that direction.
My bankify wallet is an example:
https://github.com/supertestnet/bankify
It does not verify the response received from a mint and is therefore vulnerable
Are exchanges violating Europe's MICA law by listing ethereum?
MICA says: "[Exchanges] shall prevent the admission to trading of crypto-assets that have an inbuilt anonymisation function unless the holders of those crypto-assets and their transaction history can be identified by the [exchange]." (Title I Article 76 Section 3 - full text here: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1114&qid=1735616578262)
Tornado Cash is built into Ethereum. It's a smart contract, which means it's just like a consensus rule in these respects: ethereum nodes must keep a copy of the smart contract; any eth user may use it; and as long as the majority of validators keep approving transactions that use it, the other validators must fall in line or fall out of consensus.
One might say "yeah but it's optional, so it doesn't count as built in." But aren't they delisting zcash and dash? The anonymization functions in *those* cryptocurrencies are optional too. Maybe there's some nuance about what "built in" means. I don't think the MICA law defines it. Perhaps a lawsuit should happen to get the courts to define it; possible outcome A: zcash and dash get relisted; possible outcome B: ethereum gets delisted.
I think I found it.
Title I Article 76 Section 3 says:
"The operating rules of [every] trading platform for crypto-assets shall prevent the admission to trading of crypto-assets that have an inbuilt anonymisation function unless the holders of those crypto-assets and their transaction history can be identified by the crypto-asset service providers operating a trading platform for crypto-assets."
Full text here: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1114&qid=1735616578262
I am trying to look it up for myself but I can't find the text of the law (it's called Mica)
I found an official summary document but a word search for privacy did not yield anything useful
People keep saying the law requires exchanges to delist privacy coins; in just wondering, where does it say that? What is the precise language of the prohibition? Does anyone have a quote?
defi services can still profit from other parts
e.g. they can continue taking a % of staking rewards (that's the app layer, not the frontend)
they can still run "searchers" to front-run customers
they can still receive airdrops
it's only *frontends* that mustn't make a profit
It is annoying that the new IRS defi document does not contain page numbers. (source: https://public-inspection.federalregister.gov/2024-30496.pdf) But pdf readers do.
And I note that on page 41, they clarify that a software developer is not a broker unless they get "consideration" (i.e. money) for their code. Yay!
I wonder if this means defi service providers will create a "non-profit arm" solely responsible for creating and running a frontend service
Only the frontend services are categorized as brokers, and only if they make a profit
So just keep that part profit-free and you're gold
It is annoying that the new IRS defi document does not contain page numbers. (source: https://public-inspection.federalregister.gov/2024-30496.pdf) But pdf readers do.
And I note that on page 41, they clarify that a software developer is not a broker unless they get "consideration" (i.e. money) for their code. Yay!
Poors Law
The cost of AI technology drops by half every year