Introduction

Recently I was out for a walk and I think I convinced myself that any given asic owner should theoretically make more money by pointing their asic at a hashrate market instead of directly at a particular pool, but only if there is no broker.

When I began thinking that way, there was something counterintuitive about it, which I'd like to address first.

Definitions

I'll start by defining three terms: "Owner" refers to a person who owns an asic and lists it for rent on a hashrate market. "Renter" refers to a person who visits a hashrate market and pays to temporarily rent someone else's asic. "Broker" refers to a person who runs a hashrate market — e.g. whoever bought the domain name, assuming it has a website.

The Problem

Recently I got the idea described in this document from @maveth6 on twitter. I know of three hashrate markets: Nicehash, Braiins, and Mining Rig Rentals. I define their niche as a type of broker. They not only play a matchmaking role between asic owners and would-be renters, they also custody the funds of renters while the mining is happening, and release it to asic owners bit by bit if there are no complaints from the renters. Brokers charge a fee for this work, which reduces the efficiency of the market, and, since they have custody of user funds, they are subject to various regulations. Those introduce additional friction: they KYC their users, they run incoming bitcoin through chainalysis software, they potentially seize funds if red flags are thrown, they are a honeypot for thieves, and user funds are at constant risk.

A Solution

My idea is to get rid of the broker. Instead, have people with asics publish an ad on nostr or similar stating how much hashrate they control and a price

In this document, I compare two existing technologies for paying L1 bitcoin addresses from lightning channels, and then introduce a new protocol for this.

In bitcoin’s lightning network (LN), capital is typically allocated into structures called channels where two channel users split up the total balance of a utxo via presigned transactions. Additional off-chain transactions allow the two users to modify the balance they can withdraw from their channel as well as use a procedure called “routing” to chain transactions and channels together and thus pay other people without doing an L1 transaction.

Sometimes, a channel user wants to make an L1 transaction and pay a standard bitcoin address, but all their money is in an LN channel. There are two main solutions that allow this: splice-outs and swap-outs, which I will henceforth call splices and swaps.

While recently considering the concept of “pruning” in bitcoin, a novel way to prune a large portion of the UTXO set occurred to me. Before I outline the idea, I want to say three things:

Number 1, one of bitcoin’s trust assumptions is: when your node requests block data, not all of your peers will withhold it from you. If they did, you could not sync the chain, or receive money.

Number 2, nodes with limited storage space sometimes use a technique called “pruning” to save space. While validating the blockchain, they periodically discard the oldest parts of it – all but the most recent blocks. Whenever a new block gets added to the chaintip, they discard whatever block is oldest. This means their local copy of the blockchain has a roughly constant size, usually a couple hundred megabytes, whereas “full archival” nodes (i.e. nodes that don’t prune) store the “full” blockchain – which grows constantly, and is currently hundreds of gigabytes large.

I originally wrote about how my Aggeus Market protocol works here, but I think I did a bad job and it's a bit confusing. In this document, I'd like to provide a (hopefully) more accessible description of how it works.

Fundamentally, Aggeus Market is based on the expectation that an oracle will reveal a secret Y if some possible future event happens (e.g. Atlanta wins an upcoming soccer game), and a secret N if that event does not happen (e.g. Atlanta does not win). Based on that expectation, suppose someone decides that they think the secret Y is 80% likely to be revealed, and they are willing to bet 10k sats on this outcome.

Aggeus Market allows them to do this in such a way that, if they are wrong, they lose 80% of their money (i.e. they lose 8k sats), but if they are right, they get their money back plus an extra 20% (i.e. plus 2k sats). These numbers are only an example, users can set them to whatever val

Aggeus Market is a protocol for creating prediction markets on bitcoin. The protocol needs an oracle, a set of one or more market makers, a set of one or more buyers, and a coordinator. Notably, the coordinator never has custody of anyone’s money.

Suppose a market maker named Mary wants to win money by correctly predicting the outcome of a political contest where Reginald the Republican is running against Dave the Democrat. The market is called "Will Reginald win the Reginald vs Dave election?" and its participants have Yes contracts and No contracts available for sale, each of which is denominated at 10k sats. (Throughout this document, I call such contracts Shares.) Mary thinks Reginald only has a 20% chance of winning, so she decides to create a 10k sat "Yes share" and offer it for sale for 2k sats, such that if someone pays her 2k sats and the Oracle later reveals a secret Y (meaning “Reginald won”), the buyer of her share will get 10k sats -- Mary gets to keep

Bitcoin Adoption Gamified

The Bag System is an idea for a new type of bitcoin merchant software that uses a pooled reward system to gamify bitcoin adoption. The essential idea is that merchants save money when users pay with bitcoin, and if a bunch of merchants pool a portion of those savings -- 1% -- you can pretty quickly get a really large pot of money which you can use to reward consumers who spend their bitcoin at those merchants. For consumers, it's great: they're not spending any extra money than if they paid with fiat, but they do get more bitcoin than they started with. For merchants, it's great too: only 1% of their money goes to the reward pool ("the bag"), which is like 1/3 of what "normal" payment processors charge, plus the money stays in their local community and just incentivizes more traffic to come to their store.

Today I was making a slideshow about coinpools and a thought occurred to me.

I think it’s possible to have four or more people contribute funds to a coinpool and then make withdrawals “from” the coinpool without revealing to one another which user they are. I think this protocol would require interaction from every other participant whenever anyone wants to transact, but in case of a liveness failure, I think each user would be able to withdraw their balance. I am tentatively calling this idea a “zkp coinpool.” I initially also thought the people funding the coinpool could contribute different amounts to it, but I’m less confident of this now – you’ll see why later, but the paragraph after this one starts by assuming they can contribute different amounts.

I think a zkp coinpool is possible because of zero knowledge proofs, in particular, the Zokrates software. This software lets you prove that a number X is (1) positive and greater than a number M but (2) less than a number Y (3) without disclosing the

Suppose Alice wants to route a lightning payment to Carol, who has 5 payment channels with Bob, Zeke, Yan, Xander, and Wilma. Alice may start by getting an invoice from Carol. Before giving it, Carol should make up a random 32 byte secret, derive its pubkey on bitcoin’s elliptic curve by treating it as a private key, and sign 5 messages, one for each of her channel counterparties, telling each counterparty she will give the secret to that counterparty using a scheme to be described shortly, if he holds up his end of the “bargain” encoded in that scheme (again, to be described shortly). Carol should encrypt each message so that only that counterparty can read it, then encode all of the encrypted messages in the invoice she shares with Alice, telling Alice, at the same time, which message is readable by which channel counterparty.

Now it is Alice’s turn. She should find a route to Carol by asking her own peers if they can forward a pay

The following code block gets you bitcoin's price by sampling from 5 sources and taking the median.

Usage:

(async()=>{
    var btc_price = await getBitcoinPrice();
    console.log( 'btc price:', btc_price );
})();