matthewjablack
Matt Black

https://mblack.io

CoFounder @AtomicFinance. Boomer Millenial. #Bitcoin not crypto. Nostr not blockchain

Public Key

npub1wf7w8mrzqs3uvd8wsp774462d3rtttzwetuhpmzjccgn63emy4ls5qsxhy

NIP-05 Address

matthewjablack@atomic.finance

NIP-57 Address

matthewjablack@walletofsatoshi.com

Profile Code

nprofile1qqs8yl8ra33qgg7xxnhgql026a9xc344438v47tsa3fvvyfaguaj2lcpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqguwaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skcnhrfn0

Publishing to

relay.nostr.band

nostr.bitcoiner.social

Author Public Key

npub1wf7w8mrzqs3uvd8wsp774462d3rtttzwetuhpmzjccgn63emy4ls5qsxhy

Show more details

Last Notes

2024-12-08 20:40:31 UTC

- reply

Microsoft is voting in 2 days
Amazon will vote in 2025
If Microsoft votes no, shareholders will sue, but Amazon could beat them to the punch
Bullish 🐂

2024-12-06 23:25:16 UTC

Shopify better watch out
e-commerce coming to Nostr ⚡️
#nevent1q…rjdq

2024-12-06 06:00:26 UTC

- reply

what happens when you leverage trade
https://m.primal.net/Monq.jpg

2024-12-06 05:53:20 UTC

- reply

1000 pushups per day till 1000k 💪

2024-12-05 18:14:00 UTC

- reply

100 push-ups per day till 1 mil now 💪

2024-12-05 05:23:41 UTC

- reply

Whoa! where can we get access to this?

2024-12-05 04:10:10 UTC

- reply

@npub1wyu…87ez to the rescue

2024-12-05 03:41:34 UTC

TODAY IS THE LAST DAY
Congrats to everyone that did 100 push ups per day till 100k 👏 🍻 💪
#note1sfx…msnm

2024-12-05 03:40:55 UTC

Happy 100k y’all 🍻

2024-12-05 00:16:51 UTC

Covenant support is loading 👇
LNHANCE (OP_CTV, OP_CSFS, OP_PAIRCOMMIT, OP_INTERNALKEY), OP_CAT, OP_CCV, OP_VAULT, OP_TXHASH, SIGHASH_APO are being discussed
If you're a bitcoin dev, add your opinion to the wiki
@npub1v6q…nzyr, @npub1lh2…a9nk, @npub1dge…mccn, @npub1su6…su60, @npub1u8l…turz and others have already shared their opinion
https://en.bitcoin.it/w/index.php?title=Covenants_support

2024-12-04 22:52:44 UTC

100 push-ups per day till...👀
https://m.primal.net/MnmB.png
#note1w7s…uujj

2024-09-23 22:25:29 UTC

- reply

> It appears that it might be possible for CTV to create on-chain AMM-style marketplaces. On chain marketplaces create arbitrage opportunities which motivate people to pay for faster transactions:
That article doesn't mention AMMs at all. It mentioned inscription marketplaces, like Magic Eden, which is running today, where you need to construct a PSBT to create an "ask" for a Rune (you can't even do bids). They were talking about that creating some MEV.
> Please show me where the non-technical risks were discussed. I haven’t been able to find anything other than Peter identifying the risk of cheaper OOB payments.
Great question. Let's see what folks say:
https://x.com/matthewjablack/status/1838340344607355010
utxos.org is obviously a great resource. And mailing list for previous iterations of CTV
OpTech had some things to say: https://utxos.org/analysis/optech/
> We were previously discussing AMM style marketplaces.
AMM style marketplaces can't be built with CTV.
> I suggested that perhaps specific UTXOs could represent points on the hyperbolic constant product curve (x * y = k) that’s used in AMM marketplaces.
You can't do transaction introspection with CTV, so this isn't possible
> You haven’t yet shown me why it’s impossible to create AMM style marketplaces using CTV.
You haven't shown me how you can!
First of all, you need to do multiplication to do x * y = k. You don't have OP_MUL in Bitcoin script since it was disabled back in 2010 by Satoshi. You can emulate OP_MUL using CAT in order 1400 bytes. But you cannot emulate it with just CTV.
Bitmatrix ran into this problem when they were building an AMM on Liquid. They were able to get MUL working using OP_SUBSTR and OP_CAT:
https://medium.com/bit-matrix/technical-how-does-bitmatrix-v1-multiply-two-integers-in-the-absence-of-op-mul-a58b7a3794a3
However CTV doesn't enable MUL in any capacity. You cannot create an AMM if you cannot calculate the price after a swap occurs.

2024-09-23 19:01:08 UTC

- reply

Absolutely 🎯
This thread contains even more discussion on the topic: 👇
And generally covenants using CTV open the door to doing a whole range of things *trustlessly* and *efficiently* in a very clear and understandable manner that doesn't leave room for unknown unknowns being introduced (especially compared to CAT). Commiting to ALL inputs and outputs reduces the attack vectors substantially IMO.
#note1unr…sz7k

2024-09-23 17:40:35 UTC

Christmas came early this year 🎄🔔
#note1qqq…xuk7

2024-09-23 17:38:30 UTC

- reply

> My point was that Peter had overlooked the other case, specifically the risk that CTV could motivate people to pay for faster transactions.
Why would CTV motivate people to pay for faster transactions more than any other normal transaction? I don't see how it would create more motivation for paying OOB for faster transactions than lightning or on-chain payments.
> and I don’t believe anyone can know for certain — because our assumptions are based on the past and not what people might invent in the future
CTV has been pretty well researched over the past 4 years since it's inception. It's gone through several iterations to make it safer. In fact there's been way more scrutiny and edge cases researched for CTV than was ever done with Taproot.
> I could imagine that this could be solved by the coordinator frequently reissuing the contracts with the current value.
The key thing here, is you can't exit the contract if your counterparty is offline. So once the DLC options contract is created, unless you've pre-signed for all the possibilities ahead of time, if your counterparty goes offline, then you can't exit, and you have to hold to expiry.
You could have dedicated market makers that take the other side of contracts, but that means the market maker can't exit if their counterparty goes offline, making this process very capital inefficient (not to mention you can't do portfolio margining obviously, since risk is defined within the DLC contract itself).
So unless you have all those pre-signed outcomes, you won't have secondary markets. But you won't have secondary markets without infinite compute.
So as much as I would like that use case to work, CTV just doesn't enable it.
CAT on the other hand would enable it, since you can commit to specific inputs and outputs, whereas with CTV you must commit to ALL inputs and outputs.
This is why CTV is actually incredibly conservative. At face value things that you think are possible, aren't actually possible. It's a very restrictive covenant scheme.

2024-09-22 13:35:39 UTC

- reply

> That’s true, but I think you’re conflating two services. Well, technically, there are three services (fast, regular, and slow). “Fast” would be an acceleration service for those who want faster transactions and willing to pay for speed. Regular would be the normal CPFP transaction. “Slow” would be a cheaper, slower service for those who don’t want to pay higher CPFP fees and are willing to wait.
Very fair point. However if folks are okay with “slow”, what’s the likelihood they’re also okay with just waiting for lower feerates for their tx to be confirmed in the first place?
> What if there was a registration step where traders sent the coordinator or AMM a small amount to register their address, and the contracts published the next day by the AMM would include these registered addresses?
AMMs are not possible with CTV only, because there is not sufficient transaction introspection to achieve this (aka you can’t look back at previous txs which is necessary to have the price update in an AMM).
Registration step with a coordinator is technically plausible, but in practice it’s computationally infeasible.
With CTV you need to pre-calculate all the possibility trees ahead of time.
For example, imagine you had 1 million addresses registered. You’re about to create an options contract that you want to be able to sell to any of the 1 million. So you need to precompute 1 million possibilities. Now imagine you want to allow that million to be able to also sell to any of the million registered as well. Well now you need to compute 1 million times 1 million combinations within your taproot tree script. Oh and if you want that 3rd sale to be able to sell to anyone, you need to do it again, creating infinite possibilities to compute.
On top of that, you’d need to also compute all the possible prices of the contract as well. For example dependent on the market price, it could sell for 0.01, 0.011, 0.012, 0.013 etc, etc. You’d typically have 100 possibilities for 0 to 0.1. To handle up to 1 BTC option price you’d need to compute an additional 1000 possibilities. So multiply all the previous million by another 1000 dependent on your price granularity.
So yea, you might be able to construct a transaction that is one time MEVable, but it can’t be continuously sold without infinite compute power. Additionally I highly doubt an on-chain market would ever form due to these restrictions
(Not to mention we haven’t even gotten into free option problem, since block confirmations take so long, that the potential for someone to RBF while they’re waiting for the block to confirm and they see the price move in the opposite direction makes these contracts infeasible in the first place)

2024-09-12 22:23:21 UTC

- reply

This thread debunks any remaining OOB concerns IMO
https://x.com/4moonsettler/status/1834337644496539779

2024-09-12 14:01:25 UTC

- reply

> You can use this to trade options, make atomic swaps, etc.
You can trade options now using DLCs (we pioneered this at @npub1at0…wshk)
Cross-chain atomic swaps have always been infeasible due to the free option problem (folks tried building them using HTLCs back in the day):
https://medium.com/@mchammond/atomic-swaps-eebd0fa8110d
> CTV is actually an advanced NEW smart contract platform that RUNS ON CHAIN.
I think this is a bit misleading, because it is not an entirely generalizable "smart contract platform" that creates a huge surface area of attack like you might see in Ethereum smart contracts. The surface area of attack is well defined, because you specify exactly what the parameters for exiting the locking script. You can create loops for example, but you must define when the loop ends. All possible states of the contract are defined ahead of time.
> Are you familiar with Uniswap and all the MEV opportunities created by financial trading and arbitrage?
As is mentioned in the article, MEV already exists on-chain on Bitcoin in the form of runes. People were sniping them right around the halving and selling at a higher price. And yet, all this activity died down, because it wasn't profitable. People learned that MEV is incredibly difficult to actually extract on Bitcoin, due to the 10 minute block times (which end up being 2 minutes or 40 minutes).
CTV does not enable an AMM to be created (CAT does, but an AMM is also extremely infeasible on Bitcoin due to the 10 minute block times once again, where slippage can be a huge concern).
What specific new MEV opportunities are opened up by CTV? In CTV you must constrain all the inputs and all the outputs, that you're committing to, so you'd have to specify ahead of time, which parties were able to snipe your transaction. It's not like anyone can try to snipe the transaction you were trying to do. And once again, even if someone specified a list of parties ahead of time, them sniping whatever type of contract is still incredible dangerous due to 10 minute block times, making it economically infeasible.
> This trading wouldn’t be risk if it were conducted say on Liquid and later settled on bitcoin.
Once again you can already do trading today of futures, options, bets using DLCs. But the key thing, is these contracts are all P2P, so there's no MEV opportunity. CTV makes DLCs better, but doesn't cause any new MEV opportunities.
I'm trying to understand exactly how someone would construct financial contracts on Bitcoin, that would be MEVable with CTV?

2024-09-11 19:40:59 UTC

- reply

@npub1ej4…ndrm specifically said in his post:
"The current CTV proposal in BIP-119 has only one hashing mode, known as the DefaultCheckTemplateVerifyHash, which essentially commits to every aspect of the spending transaction in the template hash. From a practical point of view this means that in many circumstances the only available mechanism for fee payment will be CPFP. As mentioned above, this is a potential problem due to it making out-of-band fee payment a non-trivial cost savings in cases where the CTV-using transactions are small."
So he's specifically saying that out-of-band fee payment could be cost savings for small CTV-using transactions.
IMO, you could make the exact same argument for lightning force closures. Even though lightning will move to anchor outputs, which means 0 fee force closures, that will be CPFP'd thanks to "package relay". Those small transactions could have cost savings with out-of-band fee payments.
But obviously, no one is pushing against package relay. For most small transactions, out-of-band fee payments would be a small cost savings.
In fact, this statement could technically be true for any pre-signed transaction scheme. Does that mean we should never have any pre-signed transaction schemes? Hardly.
So, since this issue already exists in Bitcoin and is only relevant to very small transactions, and since CTV can actually decentralize mining even more (https://utxos.org/uses/miningpools/), I'd argue these issues are known, and the concerns with not having CTV are actually a great risk to Bitcoin. Not having covenants, IMO, is a huge risk to Bitcoin custody centralization and people choosing not to self-custody.
CAT is an entirely different beast, and I agree that the risks are much more unknown.
https://petertodd.org/2024/covenant-dependent-layer-2-review

2024-09-08 21:32:31 UTC

I'm excited to be coming to @npub17yq…5269 for the first time!
I'll be giving a workshop on how to create a simple DLC wallet and bet on the presidential election
So whether you're pro-Trump or pro-Kamala, be sure to come out to Atlanta for a fun time
https://github.com/TABConf/6.tabconf.com/issues/117

2024-09-05 02:52:47 UTC

- reply

Brilliant! Let's zap it into existence ⚡️

2024-09-05 00:52:38 UTC

Idea of the day: Nostr-powered alternative to Uber Eats
One day, when #Bitcoin is the standard for payments, someone will build #foodstr. It will be an alternative to Uber Eats (for pickup only, as delivery wouldn't work), where you can pay with Lightning and order your food ahead of time.
It will save restaurants from a 10% Uber Eats fee for pickup orders.

2024-09-04 18:10:29 UTC

1000 sats to whoever claims this cashu token below the fastest 🥜 👇
How to claim?
Go to cashu.me
Save to Home Screen
Tap the receive button
Paste the token
It’s now that simple to onboard people to #Bitcoin
#note1qyw…6mum

2024-08-30 02:54:03 UTC

- reply

Yep, every time 😂
#note10a2…8c3d

2024-08-30 02:51:14 UTC

Package relay is finally coming to #Bitcoin core!
This has been years in the making
It’s a massive improvement for lightning, DLCs and statechains ! 🔥
You can goodbye to force closures caused by mempool feerate spikes!
https://github.com/bitcoin/bitcoin/pull/30726

2024-08-29 15:58:10 UTC

- reply

Is that grass fed ground beef and pasteurized eggs I see? 👀🔥

2024-08-28 16:58:24 UTC

Income tax proposed in 1913 was insane
This is preposterous
https://m.primal.net/KRyt.jpg

2024-08-28 14:06:47 UTC

How do we scale Nostr?
“Unpopular opinion: Nostr CAN'T scale to be what people want it to be. It's an all-to-all broadcast, which scales like O(n²). It will collapse in its own success.
Nostr relays are like sidechains and altcoins. It's attempting to solve an O(n²) scaling problem by having multiple copies of the same thing. It leads to Balkanization where you can't see content from or message some people.
Blockchains of blockchains were dumb and this is dumb in exactly the same way, and I can't believe all of you failed your algorithms classes.”
- Bob McElrath
So this begs the question, how does Nostr scale long term? Or do we simply expect 2 of 3 dominant relays in the long term?
cc @npub180c…h6w6 @npub1xts…kk5s @npub18am…p424 @npub1pgh…rs38 @npub1gcx…nj5z @npub18c5…0we7
https://x.com/bobmcelrath/status/1828763959001804956

2024-08-27 15:39:12 UTC

Has anyone set up a DLC oracle that publishes to Nostr yet?

2024-08-25 02:25:03 UTC

Insane feerates on Thursday were the cause of lightning force closures once again ⚡️
But luckily, there's a simple solution to solve lightning force closures once and for all 👇
And it's a solution that's coming to core very soon(ish) 🤞
https://mblack.io/posts/fixing-lightning-force-closures/

2024-08-25 02:11:51 UTC

Is there an easy way to do group chats with Nostr? What's the best client?

2024-08-24 22:42:50 UTC

Nostr > Telegram
#note1fwn…95js

2023-11-19 22:35:28 UTC

Epic thread by Brad
https://x.com/bradmillscan/status/1726349177418912193

2023-11-14 23:45:00 UTC

GF asked if I tried doing a paternity test 🤣
https://image.nostr.build/fc4f008dba6baae171581e6aeed5af56e84bba4ac58d8dc17c41fce7a274e86c.png