On bitcoin you could literally steal money with a good mempool attack, by closing a lightning channel with a previous state in your favor and censoring your peer to broadcast the real final state. There's good money to be made.
On Monero the only financial incentive is your government sponsored wage to de-anonymize users. It's motivating if got the job, but it's not like there's a sea of APT actors continuously looking on how to steal the cake, like North Korean Lazarus Group did on a bunch of ethereum L2 bridges (which I admit are much lower hanging fruits, but I'm sure one day they'll take a look into bitcoin L2s).
Sorry to see you go, hoping the best for your next projects!
I can't help but ask, it appears from the notes you posted that it's partially because of the ongoing spam attacks? Or is it unrelated and just a lack of funding or a personal shift of interest?
Really cool!
Feature request, rather than decrypting the key with the password, it should be like a seed passphrase. It would allow you to have deniability, with a decoy profile in case authorities force you to decrypt that NFC tag.
With NIP-49 it is possible for authorities to know you gave them a wrong password (or the data on the NFC tag is corrupted). But a wrong passphrase will just lead you to a another nsec, where you can put some decoy notes.
Phoenix has bolt12 addresses, but not LNURL addresses, which is what zaps uses.
Not only that, but to be used for zaps the LNURL server should implement NIP-57, at least to receive zap requests, and preferably to also publish zap receipts on nostr.
If miners ever collude to censor a transaction, the fee market create a strong incentive to break the collusion. Meanwhile the federation has no incentive, they hold the real bitcoins, the rug is done.
Not to mention mining monero is permissionless, so you can "fight back", joining the liquid federation is not.
We need an equivalent of HFSP for #nostr
Have Fun Staying Centralized?
Have Fun Staying in Walled Gardens?
Have Fun Staying Blinded by the Algo?
Have Fun Giving Your Data?
So many options...
Sounds possible with BIP-32. Generate a seed private key and give its xpub to a miner. The miner can computes as many public key as it wants by bruteforcing non-hardened derivation paths, and once it finds one that matches your criteria, it replies with the derivation path. Only you can compute the private key with the seed private key and the derivation path.
Throw away the seed once you're done, don't reuse, otherwise the miner might correlate your npubs.
Monero supply is auditable. Every time you make a transaction, you have to mathematically prove you have the amount you spent. All you have to do is verify every proofs.
Sure, the maths involved is more complex than a simple summation, but it's still maths at the end of the day. The robustness of bulletproof (the proving scheme used) has been proven mathematically, the likelyhood of crafting fake proofs is metaphorically the same as being able to mine bitcoin blocks without having to do proof of work.
(the metaphor is somewhat accurate, bulletproof literally relies on the robustness of hash functions to be safe)
With that knowledge, let's imagine how an inflation bug would look like. A bug means there's something wrong in the verification process. On bitcoin, the code would not detect an invalid transaction (because it's buggy) but anyone who knows how to sum numbers will spot that something wrong is going on.
On monero, the code would not detect it, but anyone who knows how to verify proofs will spot something wrong is going on. It's pretty much the same.
It's a bit scary because we all know how to sum stuffs (but really there isn't as many people who know how to write code that sums all UTXO), while we don't necessarily know how to verify these proofs, but there are multiple implementation of verifiers, audited and well tested.
If you're not scared of maths, I highly encourrage reading Zero To Monero, it's not that hard and really demystifies the protocol. It's not a magic black box, it's just good old maths.
And finally, I believe there's still plenty of stuffs to improve bitcoin privacy without having to go as far as obfuscating transaction amounts. If we manage to improve anonymity sets, amounts will be obfuscated by being distributed into multiple uncorrelable UTXOs (the uncorrelable is the hard part).
I'm not sure what you mean by "there is no proof". Proving you own the private key that can spend a UTXO without revealing that private key (asymetric cryptography) is also complex math, but pretty much everyone is trusting this math and has likely never tried to do it by hand. That's also a mathematical proof, although the assumption being made that it cannot be faked are vastly different.
Maybe I should have mentioned, "bulletproof" is a proving scheme that comes from academic cryptographers, just like SHA256, ECDSA and Schnorr signatures used by Bitcoin, it's not a Monero-specific protocol, although it's likely its biggest user. It follows the same scrutiny from bright and smart people.
At best we could argue zero knowledge proofs are younger than the other cryptographic primitives I mentioned, and we might want to wait to see if new schemes can offer different speed or proof size. But I believe the fear against them is largely unfounded now.
Anyway, as I said, I'm not a zero-knowledge maximalist, they are a means to an end, and the end is large anonymity sets, make multiple users indistinguishable from one another. Maybe we could manage to reach that end differently. But in our search for solutions, it would be a shame to not take into consideration the track record that some of them already have.
Well it does sound like a lack of programmability expressiveness...
When I make a payment on lightning, I pay a fee, including to relays that don't know the full route or who I am, but they can't claim that fee without fulfilling the service they've been asked for. The HTLCs make the service atomic.
Bitcoin is expressive enough for that contract, but I'm aware it might not be for more complex use cases.
I'm assuming that in order to receive their OXEN, relays have to prove they are providing the service they've been asked - either to the user, or to the network at large. If the verification of that proof could be run on a bitcoin smart contract (which, granted, might not be possible with the current expressiveness of bitcoin scripts) then their is no need for that custom token, the smart contract is the trustless arbitrator of the network.
I think this framing is worth mentioning to bitcoin maxis. Tokens do become useless with enough expressiveness, but we're not there yet.
Yeah, it should be each bitcoiner voting what they believe is spam by configuring their node!
Oh wait, that's what Luke allowed us by patching -datacarrierlimit...
Oddbean new post about login | logout
Notes by plebymous | export