I suspect it was basically intended as art. Someone thinks it's cool that bitcoin can do all of these weird things and decided to showcase them all in one transaction.

Also available here: https://stacker.news/items/593226

Analysis of 0xB10C's weird bitcoin transaction

https://telegra.ph/Analysis-of-0xB10Cs-weird-bitcoin-transaction-07-01

The Inquisition signet produces blocks according to a seemingly random Poisson distribution

That way nobody expects them

The BTC Script workshop went awesome! I think it was at least 96% close to perfection 😍 😍 😍

I also recorded it and you can purchase the video here for only $5: https://supertestnet.org/workshops.html?option=bitcoin_script

Also remember to sign up for next month's workshop, all about Nostr! https://supertestnet.org/workshops.html

Reminder: my Bitcoin Script workshop is in about an hour! Any last-minute signups, please contact me here and I will give you a lightning invoice or a bitcoin address. Join us to create your first bitcoin script and learn how to create and use an oracle on bitcoin's layer one!

Thank you @npub1f4www6qjx43mckpkjld4apyyr76j3aahprvkduh9gc5xec78ypmsmakqh9 for producing Little L2s. Thank you Ricky Nelson for the original song, Poor Little Fools, which inspired Little L2s. Thank you "Let's Sing" for the karaoke version which I used in the backing track.

I designed the workshop so that you can participate with *only* two things:

(1) a web browser

(2) a text editor

But it involves about 150 lines of javascript (all documented and explained) so familiarity with that language helps

Don't forget to sign up for my Bitcoin Script workshop happening TOMORROW at 7pm NYC time! Write a bitcoin smart contract where Alice and Bob send one another a payment that only goes through depending on the outcome of a ballgame as decided by an oracle. http://supertestnet.org/workshops.html

Thank you for purchasing my workshops! Here is the link: https://www.youtube.com/playlist?list=PLP7B5SmUZUT9H1pcQxEZkCqOQ08WPsBsd

Also feel free to join the PlebDevs discord channel if you want to follow up or have any questions: discord.com/invite/64aNz8c7

yes, here are screenshots

My latest single is Little L2s, all about a typical experience using bitcoin's "layer two" protocols

https://supertestnet.github.io/songs/Super%20Testnet%20-%20Little%20L2s.mp3

Thank you for purchasing a ticket to my live bitcoin script workshop! I will send you the link here the day before the event. Also feel free to join the PlebDevs discord channel if you want to follow up or have any questions: discord.com/invite/64aNz8c7

Don't forget to sign up for my upcoming LIVE workshop on bitcoin script! Learn how to write your first bitcoin smart contract for only $20. Happening this Tuesday, June 25, at 7 pm NYC time. Details here: https://supertestnet.org/workshops.html

welcome to nostr, npub1cp0eqtakqgwckx6eax9uwtmrz9pdh2thcgu2l3lhnedyztm0ahusdcvtcf!

Of course, almost everyone on nostr does. But not by default. We all opted in.

One of the things I really admire about bitcoin is that it has privacy by default

Because by default, nobody uses it! So there's nothing to track :D

Not yet, it isn't ready. But I am planning to write a wallet called Snuffle based on the hedgehog protocol.

I continue to work on my hedgehog protocol and I've figured out how to add some cool features to it. I wrote a "bridge server" which helps "translate" hedgehog payments into lightning payments, and it works right now, which means a hedgehog wallet can pay regular lightning invoices. I also added support for something I call "unilateral channels."

What that means is, someone can be fully offline, not even talking to you, not even aware of you, and if you have their pubkey you can send them $100 in bitcoin (for example) in such a way that they "receive" it in a new hedgehog channel. You just use their pubkey to create a multisig and fund it with the $100, then send them a string of text containing signatures for the "force closure" transactions that they need in case they have to unilaterally exit from the multisig. Then, whenever they next get online, they can paste that string into their wallet and instantly start using the money in their (already confirmed!) new hedgehog channel to make hedgehog payments and lightning payments.

You you could also use the unilateral channel feature to "make up" a bunch of keypairs, get some business cards, print out channel opening/closing information on the business cards (using the pubkeys from each of the keypairs you made up to create the multisigs), fund the multisigs yourself, and then "gift" them to people by just handing them the business card. Each recipient gets a new, prefunded hedgehog wallet with full support for sending and receiving lightning payments, with two simple steps: (1) visit a webpage (or download an app) that runs hedgehog wallet software and (2) scan the qr code to import the channel data.

All of these features have some interesting side effects. For example, since you can receive money into a new hedgehog channel without being online, you can keep your private keys fully offline in an airgapped hardware wallet, and whenever you want to send money over hedgehog or lightning, you can just prepare the transaction in your software wallet, encode it as a series of several psbts, pass those to your hardware wallet for signing, and let your software wallet send the newly signed transactions to the bridge server.

You could also *receive* money over lightning into a separate hot wallet, and regularly withdraw it to a cold hedgehog wallet by using your hardware wallet to individually sign the various transactions that are involved in receiving lightning payments and revoking old state (but this requires implementing support for receiving lightning payments on hedgehog, which I haven't done yet -- see below).

I am currently working on a feature that I call "virtual channels" which allow you to make a unilateral channel without going on chain. This lets you cheaply give people hedgehog channels that "fully" work, with the tradeoff that you (the sender) have a copy of this virtual channel's private keys, so you have custody of the recipient's funds. But the channel works just like a regular hedgehog channel, with the same interface, its own balance, full support for sending and receiving hedgehog payments, and sending lightning payments. So it's sort of like you're hosting an lnbits wallet for someone, only with hedgehog's ability to effectively emulate asynchronous payments. Which means you don't need a server to host this software, a regular phone or even a web browser should work fine, because you don't need to be online all the time, only the bridge server does.

Once virtual channels are ready I want to add support for "receiving" lightning payments into a hedgehog channel. I wrote up a specification for it here (https://github.com/supertestnet/hedgehog-advanced) but I haven't implemented it yet. Once that is done I think hedgehog will be ready to implement in a "real" wallet. It will have so many cool features:

- keep your keys airgapped and still (a) send hedgehog payments (b) receive hedgehog payments (c) send lightning payments (d) regularly withdraw lightning payments from a "hot" wallet into .your airgapped hedgehog wallet without needing to do any base layer transactions

- if exchanges like kraken or swan add support for hedgehog, any user who has monthly or weekly autobuy enabled could receive these regular purchases of bitcoin directly into a hedgehog wallet -- hot or cold -- and be able to spend the money on lightning or hedgehog as soon as it confirms, without needing to come online til they want to actually spend the money

- if you are sending someone money and your recipient is *on*line, you can use a hedgehog wallet as a regular lightning wallet

- if your recipient is *not* online, you can pay them by making a unilateral channel for them on the base layer, and to do that you just need to be willing to pay a base layer tx fee and know one of their pubkeys (technically that part is optional, as you can just make up a keypair for them -- though I personally wouldn't trust a keypair that some rando made up for me and I would sweep all funds from such a channel whenever I next got online)

- if your recipient is not online and you don't want to incur a base layer fee, you can make a "virtual" (i.e. custodial) unilateral channel for them and deposit whatever amount you want to pay them into that. You can then send them its details and go offline, and they can sweep it whenever they next get online, without any further help from you (i.e. you don't need to be online when they sweep the funds! They just need the bridge server to be online)

- this emulates asynchronous lightning payments pretty effectively, without the need for the sender to run a server or rely on a third party custodian. But there is a "first party" custodian -- the sender retains custody of the funds in a virtual channel until the recipient sweeps them. And there is a third party bridge server, who can censor payments, though if that happens, the sender can just retry with a different bridge server and stop using the old one

- it also emulates "pull" payments, which are useful for subscriptions. If you want to subscribe to twelve months of bitflix, you can send bitflix twelve virtual channels where each one has a timelock on the virtual channel opening transaction. This effectively means that the first virtual channel cannot be used til 1 month goes by, the second one cannot be used til 2 months go by, etc. As each timelock expires once per month, a single virtual channel becomes usable each month. This allows bitflix to sweep funds from one channel per month, thus "pulling" pre-authorized funds from your wallet according to a predetermined schedule

- if you ever want to cancel such a subscription, just make a new transaction with the bridge server overwriting all the remaining virtual channels you gave to bitflix. The bridge server will then stop treating the virtual channels as valid, because they can no longer redeem the money in them even if it comes to their side of the virtual channel, so bitflix can't use them anymore either, and thus your subscription is effectively canceled

- all of this can work just fine today without waiting for bitcoin *or* lightning to upgrade -- which I think is just amazing!

I guess I find that sentiment a bit tongue in cheek, intended to insult whatever the project is by saying it could "just" use SQL

In my opinion SQL is quite awesome and when a project opts for it as a data store I assume it's a wise choice

I wonder if rampant bitcoiner hatred toward SQL is because of the catastrophic Berkeley DB bug that led to one of bitcoin's only hard forks. Berkeley wasn't *originally* a SQL db but it added support in version 11. Leveldb, which we switched to, still doesn't support SQL queries.