My latest essay is "Connector Swaps" -- a new proposal for swapping from LN to L1 in only 1 transaction

I compare the new proposal with alternatives including Splices, Submarine Swaps, and my own Papa Swap protocol that I implemented last year

https://gist.github.com/supertestnet/1844b927ec6e9e17d476a5fc2d691668

Continue

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.

https://youtu.be/Op9p3LR68fE

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.

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

You and I can help change that!

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.