This cool new block explorer emphasizes the data footprint of various transactions, especially the difference segwit made: beta.satoshi.space H/t x.com/uanbtc

The best marketing is true

Looks like it

I think this news indicates that one aspect of the marketing by Ocean Pool and DMND Pool has been effective. Namely, enough hashers want a say in how the blocks they produce look, that older pools are trying to find ways to give them that say, lest they go to pools that offer it. https://x.com/i/status/2078129671728722053

Your new rules would ruin bitcoin by potentially freezing the funds of innocent users. My mindset is to oppose such efforts. I hope y'all fix bip110 and try again later. Maybe y'all can get more support with a better bip.

> Lightning itself can't natively split payments I think it can. If the wallet knows it wants to pay 400 sats to Alice, 300 to Bob, and 500 to Carol, it can arrange a route that passes through each of their nodes, and drop pending fee htlcs off at each one, whose value corresponds to the amount desired for that node. The last node reveals the preimage and then everyone gets paid. That's an atomic split payment that lightning has native support for.

It will only activate on nodes that are running bip110, and those nodes will stop accepting bitcoin blocks almost immediately after they activate the new rules. Leading to yall being on a dead chain with no blocks, no exchange support, and no network effect. Sayonara.

I would love it if a web wallet similar to coinos allowed me to give it a list of N preimages and have it create the next N lightning invoices using those preimages. This would allow me to make a digital downloads store that has no backend logic. I could upload files to my server that are encrypted with a certain key, and then use the web wallet to sell users "secret" preimages which, when added to a corresponding "public" string, create the decryption key. The logic could therefore all be done on the frontend: show the user an invoice, check if it is paid via the web wallet's api, get the preimage, construct the decryption key, and give the user their now-decrypted file. Thus the server for a webstore could be a simple file storage system, such as Github Pages, and all the logic could be done on the the frontend, except for the delivery of the secret, which is done by the web wallet, in a way that the frontend can detect.

A bittersweet day approaches. In this, the last period before mandatory bip110 signaling, there are so few blocks left that even if bip110ers mined them all, they would still fail to achieve 55%. So they will fork off in 1018 blocks. Come back with a better proposal than bip110.

I would love it if a web wallet similar to coinos allowed me to give it a list of N preimages and have it create the next N lightning invoices using those preimages. This would allow me to make a digital downloads store that has no backend logic. I could upload files to my server that are encrypted with a certain key, and then use the web wallet to sell users "secret" preimages which, when added to a corresponding "public" string, create the decryption key. The logic can therefore all be done on the frontend: show the user an invoice, check if it is paid via the web wallet's api, get the preimage, construct the decryption key, and give the user their now-decrypted file. Thus the server for a webstore could be a simple file storage system, such as GitHub pages, and all the logic could be done on the frontend, except for the delivery of the secret, which is done by the web wallet, in a way that the frontend can detect.

BIP110 reached 1% of hashrate today. 18/(1743+18) = 0.0102 I recommend reviewing my URSF110 proposal: https://github.com/supertestnet/ursf-110

It's plausible, but unlikely imo. I suspect 95% or more of miners aren't concerned about this fork. They are unlikely to signal unless they suddenly gain an interest in doing so, and nome seems forthcoming. It's probably not even a discussion point in their decision making meetings. I suspect that, other than miners who are already part of Ocean, any miners who *do* analyze their options during decision making meetings will discuss it in terms of two options -- signal or ignore -- and they'll decide that ignoring it improves their bottom line. This is because, if they ignore the 110ers, about 2% of miners will fork off, and cease to be competition. That means the relative share of hashrate from the remaining miners effectively grows, which means they earn more money. In other words, if a miner named Billy currently has 10 exahash, and the entire bitcoin network together has 1000 exahash, then Billy has 1%. The pro110ers seem to have about 20 exahash, which is around 2%. But they are about to effectively go offline, bringing the total down to 980. So if Billy just ignores this, he'll end up with 10 exahash out of 980, which is 1.02% -- a slight increase. That should make Billy more profitable, so my naive analysis of game theory suggests miners who have ignored this drama so far will want to continue to ignore it once mandatory signaling starts.

> End receiver has to share that invoice though I assume? It's not strictly necessary. You could use a keysend payment to pay a group of nodes atomically without getting an invoice from the recipient. But if you *do* get an invoice from the recipient, that doesn't mean you are trusting him. The invoice need not contain a list, created by the end node, of the people to pay. It *could* contain such a list, since ln invoices support custom fields; but it could also just be an ordinary ln invoice, and the sender could choose what additional nodes to pay through some out-of-band method. The point is, LN routing works by atomically splitting a large amount into small sums which are dropped off node by node, atomically, and this can be turned into a payment splitting function by rendering each payment as just a large routing fee. But it has some drawbacks, like not working well if a recipient does not run a routing node.