Evidence against reusing a monero wallet: “If you need perfect unlinkability of your receivables, the only solution remains to use a separate seed (separate Monero wallet).” source: https://docs.getmonero.org/public-address/subaddress/
Evidence against reusing a monero address: “To prevent the payer from linking your payouts together [you must] generate a new subaddress for each payout.” source: https://docs.getmonero.org/public-address/subaddress/
Evidence for running a monero node, not a phone wallet: “It's always advisable, especially for privacy-conscious users, to use a personal node when transacting on the network to achieve the highest rate of privacy.” source: https://www.getmonero.org/get-started/faq/
Evidence of difficulty of using monero on tor: 
> he complete REFUSES to ever acknowledge the UX problems
I acknowledge that UX problems exist in LN. I deny that similar problems are absent from monero.
Per the monero website, here are some UX problems with monero:
- Users shouldn't reuse a monero *address*
- Users shouldn't even reuse a monero *wallet* (i.e. you should delete your wallet after each use and make an entirely new *wallet* for the next use, according to the monero website)
- Users should run a monero node, not a phone wallet
The website doesn't say the following thing, but users should also use tor/i2p/vpns if they use a monero *node,* but it's needlessly difficult to do so because many important people in the project basically disagree with that. The monero github even says in its readme "Monero isn't made to integrate with Tor" and discusses the hoops users need to jump through to get it to work with tor. It's got serious UX problems and most monero influencers just don't want to admit that because the phone wallets are easy -- and the monero website recommends not to use those!
> DNMs won't use lightning
The following DNMs use lightning:
Robosats: http://robodexarjwtfryec556cjdz3dfa7u47saek6lkftnkgshvgg2kcumqd.onion/
Bisq: https://bisq.network/
Shopstr: http://sva5te372puuuyhnp4mrspewm76x2jqnzgctdfde474owrdonu4xyoyd.onion/
> exchanges don't ban lightning
Oh yeah? https://protos.com/kraken-drops-lightning-network-in-germany-for-regulatory-issues/
Here are three interesting pages on the bitcoin wiki:
P2SH votes - https://en.bitcoin.it/wiki/P2SH_Votes
Segwit support - https://en.bitcoin.it/wiki/Segwit_support
Covenant support - https://en.bitcoin.it/wiki/Covenants_support
All three gauge developer support for various fork proposals around at the time. Kind of like a vote.
Core fans lately
If it was exactly 7%. But it's not, it varies higher and lower than that. 7% is just the average
Seems like it sets a precedent for setting confiscation deadlines in new bips
Even bip16 seems to create a confiscation deadline. It says all txs created after the deadline should have the new rules applied to them. So the ~5 people who previously used hash160 hashlocks would have to move those utxos before the deadline or else their outputs would become unspendable. Which is exactly what happened; one such output was already moved, the rest did not move and became unspendable.
The United States Congressional Budget Office has published an annual projection of future US national debt every year since 1984. They also sometimes review how accurate past projections were. Unsurprisingly, they typically underestimate the debt by 7%.
https://www.cbo.gov/publication/55234
I looked into it further, and it looks like bitcoind actually does confiscate some pre-P2SH outputs. For the sake of "simplicity," it applies the p2sh rules to all transactions in all blocks (including pre-P2SH blocks) except ones occurring in one specific block that the devs made a single exception for. Thus, the other exceptional outputs are now unspendable.
I looked into it further, and it looks like the codebase actually does confiscate those outputs. For the sale of "simplicity," it applies the p2sh rules to all transactions in all blocks (including pre-P2SH blocks) except ones occurring in one specific block that they made a single exception for. Thus, the other exceptional outputs are now unspendable.
Perhaps whoever posted that should be corrected, then. Also noteworthy: there are transactions from before bip16 with outputs that match the bip16 template, like this one: https://mempool.space/tx/9c08a4d78931342b37fd5f72900fb9983087e6f46c4a097d8a1f52c74e28eaf6
And some of them were spent, including that one: https://mempool.space/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192
Per BIP16, I think they should be treated as simple hashlocks, i.e. if they have a redeemscript, it should not be evaluated, as bip16 wasn't active yet. But block explorers like mempoolspace display these txs as if they are P2SH spends, i.e. they DO evaluate their redeemscript. (See screenshot.) I suspect that's a bug.
Interesting, was the P2SH upgrade confiscatory? https://bitcoin.stackexchange.com/questions/115803/did-the-p2sh-bip-0016-make-some-bitcoin-unspendable/115804
An LLM told me it's because the pre-segwit sighash algorithm predated the bip process, but it still seems appropriate to me for an informational bip to specify how to do such things
One of the things I like about bip143 is its detailed specification of the segwit sighash algorithm, screenshot attached. Why isn't there a bip that outlines the corresponding specification for pre-segwit (legacy) transactions?
My latest invention is Lotto Miner, a webapp where you can attempt to mine a bitcoin block in your browser and put the block reward directly in a bitcoin address of your choice. You can also mine on regtest, where you are more likely to succeed.
Try it here: https://supertestnet.github.io/lotto_miner/
Video demo: https://www.youtube.com/watch?v=1w8Fq8HejhU
The difficulty setting is low at first, but you can increase it til it matches that of the real bitcoin network. Raising the difficulty will take increasingly more work and, probably, more time.
The source code is: https://github.com/supertestnet/lotto_miner
I made this to help folks learn how bitcoin's difficulty assessment algorithm works and gain an appreciation for how much work goes into mining bitcoin blocks. Also, I'm not aware of any open source tools for creating custom bitcoin block templates on regtest, and this is a starting point for such a tool. The codebase is pretty small and since it produces valid regtest blocks, devs should be able to customize it to suit their regtest needs.
Try it out and have fun!
In its current version, this block explorer *does* need electrum, because that's where node_faker gets its block data from, which it passes to wild_explorer.
However, I *could* make a version that talks directly to a real instance of bitcoind instead of node_faker. The would node would need txindex=1 enabled, but it could work.
That said, there is already a project that's designed for that use case: https://github.com/janoside/btc-rpc-explorer -- so check that out if you're interested in an electrum-free block explorer
can you give an example of another type of node?
My two latest inventions are Node Faker, which simulates bitcoin-cli and bitcoind in the browser (via javascript), and Wild Explorer, which is a block explorer that talks to Node Faker to get its blockchain data
https://www.youtube.com/watch?v=QAc4L7tSZMs
For more info, see their respective githubs:
Node Faker: https://github.com/supertestnet/node_faker
Wild Explorer: https://github.com/supertestnet/wild_explorer
But why is that rule there in the first place? Answer: for moral reasons -- because doublespending enables fraud
> Nowhere did the white paper mention the word "fraud"
It uses it three times
