Any way for Canadians to try it nostr:npub153xmex42x4chdf757hp3q6zxagykkek7pdgwuwd074964dkyha9s82ryu8 ?
Amazon shareholders propose adding #Bitcoin to it's treasury
WILD
Laser eyes till 1 mil 🍻
Whoa! where can we get access to this?
TODAY IS THE LAST DAY
Congrats to everyone that did 100 push ups per day till 100k 👏 🍻 💪
nostr:note1sfxfae04vgszkrawgrh2zcvxhckxvd6ta390jlp8kfmvyng507qqammsnm
Happy 100k y’all 🍻
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
nostr:npub1v6qjdzkwgaydgxjvlnq7vsqxlwf4h0p4j7pt8ktprajd28r82tvs54nzyr, nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk, nostr:npub1dgesr3zcgyjv2z0050h7auzdlf88gycry7tlk7wsypmgngy97yxqv4mccn, nostr:npub1su60ga79paqea8kgkp52qeq4eduhtexc957m8utg4704xddprf4szmsu60, nostr:npub1u8lnhlw5usp3t9vmpz60ejpyt649z33hu82wc2hpv6m5xdqmuxhs46turz and others have already shared their opinion
100 push-ups per day till...👀
nostr:note1w7spume7wc4ehw7a5tcq6kcswe5texv5hg3c3djzn355eaaw7xnsvhuujj
TIL about https://nak.nostr.com/
Great tool for decoding nostr events, pubkeys, etc.
GM 🥩 🍳 ☀️
GM 🥩 🍳 ☀️
#foodstr
> The term “AMM” appears 19 times in that article. 🤷♂️
It doesn't talk about AMMs in relation to CTV creating on-chain AMM-style marketplaces
> You don’t need introspection if the addresses are preregistered. Scanning the address will list all the UTXOs. Once you know the UTXOs then you also know the amounts.
The need for introspection relates to needing to look at the previous price of the AMM, to determine what the new price should be. It doesn't matter who previously did a trade for calculating the price, just that someone did, and you can verify that someone did.
> No, you don’t need multiplication if you can determine the product in another way. You might be able to create a state machine through a chain of predefined UTXOs that represent the AMM’s balance ratio.
I'm not sure how exactly this would be done, but even if it were possible to validate or invalidate certain pathways, you would still need a ridiculous amount of compute for this. CTV commit to all inputs and outputs, so you need to compute for all the possible prices for all the possible participants ahead of time.
You run into the infinite compute problem again
The key thing with CTV, is all possible states must be known ahead of time. So AMM with price x and pool of a,b,c,d....z users
All that must be precomputed. It's virtually impossible to precompute all the possible states of an AMM ahead of time.
This is specifically because you're committing to ALL inputs and outputs. If it was only committing to a subset of inputs and outputs, then you wouldn't need to precompute all the possible states ahead of time.
> CTV would enforce that only valid state transitions can occur by committing to specific transaction templates. If input A and input B, then move to point on the curve #1. But if input A and input C, then move to point #2. You’re determining the product based on the inputs provided. It has the same effect as multiplication, just doesn’t require computation or introspection.
This is an oversimplification of all the possible states. Also there isn't a good way to add funds to the AMM. You'd need to calculate all the possible states ahead of time when folks first add funds. And you'd also have to precompute anyone on the registrar that could add funds, for any amount. You'd also need to precompute anyone being able to withdraw funds from the AMM for any amount ahead of time too.
Like the number of states you need to precompute, makes the entire thing impossible.
> Looks like nobody responded with any information showing the non-technical risks were considered. I still haven’t seen anything either. It’s on the proponents to show safety. It would be negligent to not fully consider all risks.
Yea ended up getting limited visibility on that post. The main resources I've seen have been on mailing lists. But many of them were also for old versions of CTV.
The BIP119 PR is probably the best resource for risks discussed:
https://github.com/bitcoin/bitcoin/pull/21702
For example:
- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-825557354
- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1106795814
- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1107666137
- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1129462467
- https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1335764227
Most of these concerns seem to be related to getting consensus on the change or confusion about the change, and I think one concern is related to complexity (raised by John).
> 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:
However CTV doesn't enable MUL in any capacity. You cannot create an AMM if you cannot calculate the price after a swap occurs.
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.
nostr:note1unr7mt6w06lax85e59dyyt9gc3mcth34sy4rue26f297rlkk64yss6sz7k
Jingle, the wonderful dynamically customizeable relay, is back for revenge: simpler, faster, prettier, and this time with no undebuggable C library bugs, only all the other types of bugs.
Again I am looking for beta-testers: https://github.com/fiatjaf/jingle/releases/tag/v0.1.0
Christmas came early this year 🎄🔔
nostr:note1qqqxy0673xv0hz2u40ll2c6eaym6nq78qp775fn2q7h65mj5svzq86xuk7
> 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.
> They open the door to future mining centralization.
Can you elaborate on how they increase mining centralization?
From what I can see, CTV actually reduces mining centralization, by making trustless coordination-free mining pools possible. Since coinbase transaction can be constructed to send funds directly to a covenant that miners can later claim their funds from in a trustless manner, it'll dramatically reduce the reliance on pool operators for larger miners.
https://utxos.org/uses/miningpools/
> Maybe someday there will be an existential scaling crisis, but we don’t have one right now. The mempool is clearing at a few sats/vbyte.
You could make the argument that the mempool is clearing at a few sats/vB because not enough people are actually practicing self-custody. Most of the activity is on centralized exchanges or ETFs. Vaults make self-custody way more feasible and safe.
> There are also alternatives that devs haven’t yet explored. We should exhaust all reasonable alternatives before proposing a core protocol change.
Yes that is true for covenants. You can "technically" simulate a covenant on Bitcoin today by locking UTXOs with a key that must be provably destroyed. Before destroying the key, you presign the unvaultiong transaction with the spending paths you wish for the covenant.
But let's be honest, the concept of needing to literally provably destroy the private key is an incredibly terrible process prone to error. And relying entirely on pre-signed transactions to get your funds back is just terrible as well. Instead of having to backup seed phrase, you need to back up pre-signed txs.
> We should instead identify key use cases (vaults?) that are absolutely essential (that can only be solved with a core protocol change) and build specific solutions, scoped as narrowly as possible to prevent unintentional side effects.
Ironically the solution that enables effective vaults (OP_VAULT) relies on OP_CTV support
IMO risks for CTV are very well defined, and every action commited to in CTV is well defined as well
GM ☀️ 🥩 🍳
#foodstr
> 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)
Had a great time talking about #Bitcoin covenants at TheBitcoinBay meetup last night
Lots of folks are excited about CTV and CAT and the possibilities they bring for better self custody, better lightning, better scaling and more
