My latest invention is SSB Playground: play with the bitcoin bug commonly called the Sighash Single Bug. I demonstrate that it lets you do a basic form of transaction introspection and even enforce restrictions on the output count of future transactions.
Play with it here: https://supertestnet.github.io/ssb_playground/
Or check out the source code: https://github.com/supertestnet/ssb_playground
A complete list of affected utxos are provided in the stack exchange post I linked to. You would spend them before bybprovoding the preimage to the hash160 hash as the only thing in your redeem script. After the change, you also have to hope the preimage is a valid bitcoin script and then hope you can provide any requisite arguments required by that script to make it return true, and provide those in your redeem script as well.
Here's a cool piece of bitcoin script lore about an obscure difference between two ways to use timelocks:
"height-locked transactions are standard before they’re valid, but timestamp-locked transactions don’t become standard until they’re valid"
Source: https://medium.com/summa-technology/the-bitcoin-non-standard-6103330af98c
This means bitcoin has two different types of timelock errors it can throw. It can say "your timelock isn't passed yet, so your tx is invalid" or "your timelock passed according to your system clock, but the network hasn't confirmed this, so your tx is non-standard"
It seems weird to have such a similar error be part of the validity check AND the standardness check. But as pointed out in the post I linked, this is because "transactions that are still time-locked are not just invalid, they’re also non-standard."
Here's a cool piece of bitcoin script lore about an obscure difference between two ways to use timelocks:
"height-locked transactions are standard before they’re valid, but timestamp-locked transactions don’t become standard until they’re valid"
Source: https://medium.com/summa-technology/the-bitcoin-non-standard-6103330af98c
There is a fork maintained here with different policies for measuring miner health: https://mempool.guide/graphs/mining/pools#3d
I think they show yellow if they detect evidence that some miners in that pool are refusing to mine some valid transactions that mempool.space's tx selection algorithm says it expects to get mined
Merry Christmas!
I believe mempool.space ranks miner health based on how similar their blocks are to the ones predicted by mempool.space's tx selection algorithm, which is itself based on the one in Bitcoin Core. Many Ocean miners run Knots, which has a different selection algorithm by default (it ignores certain types of spam transactions), so lots of Knots blocks don't match mempool.space's expectations, and I think that's why they give them a relatively low health score
Ocean Mining climbed back above 20 exahash (currently at 22.40) and put it to good use in the last 24 hours, mining 6 blocks when only 3 were expected. Mempool.space's measurements make it look like they have 44 exahash, but that's just because they got lucky today.
Facebook Marketplace is
I don't think the others have marketplaces
> when Robosats does ANYWHERE near the volume paxful was doing
then you can talk about similar threat models. not before.
If they did not apply the threat model when small, then the operators' personal information would be compromised before they get big.
> shopstr does essentially zero volume
Where are you getting those statistics?
> which is bullshit
If "create an entirely new wallet for every tx" is bad advice then maybe submit a PR to withdraw that advice from the monero project's website
> most LN users transactions [are] trivially linked together by their custodian or the one or two LSPs they have a channel with
I acknowledge that most LN users are not using it in a privacy preserving way. Do you acknowledge that most monero users aren't?
> Is that difficult?
Yes, for most people. Manipulating configuration files requires a lot of background knowledge that most people don't have. Using command line arguments too. You also neglected the part about installing linux in the first place, and then installing tor.
For most people, I suspect they would assume "installing tor" means "installing the tor browser," not running "pkg install tor" or "sudo apt install tor" or whatever it is since it depends on which linux operating system you're using.
And if someone gets past all that, then you have to somehow find out that (1) you have to keep it running (2) the port switches from 9050 to 9150 if you're using tor browser -- and if you're on Windows, everything is different there too.
So yeah, it's difficult. Not for me or you, but we've got a lot of background knowledge that you can't assume for most people.
> Making a new wallet per transaction is schizo IMO
Yet -- according to the monero website -- that's the only way to get transaction unlinkability in monero. You think *lightning* has a UX problem? Meet monero.
> your criticisms about having to make new addresses and the like are all REQUIREMENTS for bitcoin on-chain even to the same vendor. You can reuse the same address with the same person with Monero's and there will be no on-chain link
There will be no "on-chain" link, but that person will have an off-chain link that is just as provable. An identical thing is true for monero's addresses and bitcoin's xpubs: if you trust the sender with your privacy, you can give him a monero address or a bitcoin xpub (or a bitcoin SP address, more recently) and if he reuses it, then "on-chain" there will be no link between different transactions sent by that person. Unless the sender makes mistakes too. But even if he does everything *else* perfectly, he made this mistake: he kept your address or xpub and reused it -- and that means he kept a record or proof that links multiple transactions together. If the address or xpub leaks to untrustworthy people, e.g. if he is subpoena'd for that information, your adversaries learn those links and can prove them in court. I think that's a terrible for privacy. Do you? Or is it only bad when it applies to bitcoin, and perfectly fine in the case of monero?
> Please do proper journalism by using the protocol you describe
I've used monero plenty and I think it sucks.
Oops, I meant "your LN transactions to me"
Then how come I can trace my xmr transactions to you but you can't trace your xmr transactions to me? I'll even use Phoenix if it helps you
> STN starts talking about problems with bbllpckchain privacy, but somehow makes it all about Monero
These problems apply to other blockchain-based privacy systems too
The fact that other terrible systems also have these problems is no excuse for monero
To get decent privacy on monero, you have to install and configure a monero node
Might as well get superior privacy by installing and configuring an LN node instead
Do those monwro wallets also show a contact list? Such features encourage address reuse, thus creating additional UX hurdles -- if you recommend a "user-friendly" monero wallet, you're probably recommending a privacy-harmful monero wallet
I linked to the Tor domain
Thanks to clearnet proxies, any dnm can be used on clearnet
They are DNMs if they are a marketplace accessible via Tor or similar, there is no requirement that they somehow eliminate all clearnet versions too
> I don't understand why it's worth the effort to make a big deal out of the address reuse mistake
Because address reuse is bad for privacy (the monero website recommends against it) and yet most monero wallets are designed to encourage it
> does lightning not have bolt12 and lnurl? if you reuse these, the sender will infer that it's you both times
Yes, that is equally bad for user privacy
> You need to look into timing analysis and BGP vulnerabilities in the Tor protocol
While looking at that, also look at how those vulnerabilities apply to monero's Dandelion protocol: https://arxiv.org/abs/2201.11860
Key quote: "our analysis of Dandelion and Dandelion++ indicates that they do not offer high anonymity either…an adversary that controls 20% of the nodes…[can] intercept [enough] transactions [to where] the median entropy is about five bits…equivalent to 32 possible originators per transaction."
> These are NOT dnms and he knows it
They are per the definition used by law enforcement and by wikipedia. If you've got a strange stricter definition of "it only counts if drugs are widely sold there," that's a you-problem
> These onion services have completely different threat assessments than a DNM
Nope. They have very similar threat assessments, for the following reason: