supertestnet

Name: Sloppy
Video: https://www.youtube.com/live/5Ty7eimij08?si=1yBNEe0tA7YFMSGM&t=5038
Desc: a nostr bot that runs an LLM that tries to earn money by being funny, and uses its earnings to pay for its own hosting – such that it dies if no one finds it funny enough
Other links: savesloppy.org

Name: SatsGuardian
Video: https://www.youtube.com/live/5Ty7eimij08?si=HA3325oxhU1DwWvA&t=5411
Desc: A base layer services that watches the mempool. If it detects an unauthorized transaction from your cold wallet, it tries to use RBF to recover your funds
Other links:

The chart below is in logarithmic scale:

source of chart

It charts the growth of cpu speeds in comparison with the VAX 11/780. It suggests that Moore’s law stopped applying around 2003. I decided to continue the chart using gigaflops as a metric for cpu speed and allowing for multi-core cpus.

I don’t have data on how many floating point operations the VAX 11/780 could do but I suspect it is “none” because I think the first cpu advertised as being capable of floating point operations was the Intel 8087 in 1980.

Funding tx

Have an Oracle create a utxo like I do in tornado factory, where all the money in an n-of-n utxo goes, at first, to the Oracle, and where each key in the n-of-n is actually a 2-of-2 “sharded key,” where a statechain operator has one shard and the Oracle has the other. People can pay 10k sats to the Oracle to “buy” one of his or her shards. With it, the buyer contacts the statechain operator and obtains a cosignature on a tx that gives them the right to withdraw 2 10k-sat increments of the money from the n-of-n utxo (per my tornado factory protocol), except their withdrawal txs are not valid unless the Oracle says the result is a Yes (or No, if the user bought No). I will call these “right to withdraw” keyshards RTWs and those are what you’re buying and selling in these markets.

Connectors versus adaptor signatures

The above idea relies on the assumption that you can only withdraw using your signature if the Oracle announces a result in your

Burrow

Burrow is a proposal for a federated coinpool on top of hedgehog channels. The coinpool can have a bunch of cool properties:

a single-honest-party assumption, so the federation can't rug any user unless the keyholders in the federation are all scoundrels
users can onboard into the pool without an on-chain transaction (e.g. maybe you send in coins via lightning, or maybe another user gives you your first coins from within the pool)
every onboarded user gets their own wallet interface with their own personal balance and Send/Receive buttons

Unnamed Noncustodial Inchoate Sidechains On Bitvm (Unisob)

I have an independent bitvm sidechain model that works without a federation. Instead, there is a "bridge operator" who assists with depositing money to the sidechain as well as with the "happy path" of withdrawing from the sidechain. In my version, you can withdraw even if the bridge operator ceases operations, because there is also a "sad path" that does not require his ongoing cooperation

the main idea is that when you want to deposit money onto the sidechain you should get a "withdrawal contract" from the bridge operator

the withdrawal contract is done in bitvm and it basically says, if you (the withdrawer) can provide a proof of a valid withdrawal request from the sidechain, the prover has up to X blocks to supply proof that he sent you your money on bitcoin

if he does not supply that proof, you may slash him and take the funds that way

	name, custody, number, type
	Alby Go, self custodial, 1_000, wallet
	Aqua Wallet, custodial, 10_000, wallet
	BTCPayServer, self custodial, N/A, wallet
	Balance of Satoshis, self custodial, N/A, wallet
	Bare Bitcoin, custodial, 1_000, exchange
	Bipa, custodial, 100_000, exchange
	BitBanana, self custodial, 1_000, wallet
	Bitkit, self custodial, 1_000, wallet
	Blixt, self custodial, 5_000, wallet

	<!DOCTYPE html>
	<html>
	<head>
	<script type="text/javascript" src="https://cdn.jsdelivr.net/npm/[email protected]/dist/ccxt.browser.min.js"></script>
	<!-- the manual for using the ccxt library is here: https://github.com/ccxt/ccxt/wiki/ -->
	</head>
	<body>
	<script>
	(async()=>{
	var date = "2016-07-26";

	Recently, while discussing covenant proposals on twitter, I had this conversation (slightly modified):

	-------------------------------------------------------------------------------------------------------------------------------

	Me: Several [covenant] proposals make privacy pools like TornadoCash easier to build on bitcoin so...get on board for the "more privacy" reason! (I think you can build a TornadoCash-like privacy pool with any of the following: op_ctv, op_txhash, op_vault, op_cat, or op_paircommit)

	Other person: Just a dumb question, a proposal like coinpool or joinpool (tornado cash like privacy pools on CTV) AFAIK requires all the users to stay online so it is possible to interact with the pool. Is it possible to make it tornado cash like, meaning I can open the wallet, deposit into the pool, turn off my PC, and after months I can withdraw the funds?

	Me: Tldr: yes I think its possible. Long answer: I think I could make that kind of pool with three primitives: blind signatures, transferable stat

	//dependencies:
	//https://unpkg.com/@cmdcode/[email protected]
	var sha256 = s => {
	if ( typeof s == "string" ) s = new TextEncoder().encode( s );
	return crypto.subtle.digest( 'SHA-256', s ).then( hashBuffer => {
	var hashArray = Array.from( new Uint8Array( hashBuffer ) );
	var hashHex = hashArray
	.map( bytes => bytes.toString( 16 ).padStart( 2, '0' ) )
	.join( '' );
	return hashHex;

	https://mutinynet.com/tx/5e2be1456d1917338729449e60913781fe12b008b5b32cd76eacb953f66bd636

	```html
	<!DOCTYPE html>
	<html>
	<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, user-scalable=no">
	<script src="https://cdn.jsdelivr.net/gh/6502/sha256@main/sha256.js"></script>
	<script src="https://unpkg.com/@cmdcode/[email protected]"></script>