PolyD_

Sats. Seeds. Shells.

Public Key

npub1775tuvua6h9mkmlqm3ragxpv3z3eegahhshydj36u2xq72vve9lsq29jcw

Profile Code

nprofile1qqs00297xwwatjamdlsdc375rqkg3guu5wmmctjxegaw9rq09xxvjlcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsjkasuh

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1775tuvua6h9mkmlqm3ragxpv3z3eegahhshydj36u2xq72vve9lsq29jcw

Show more details

Last Notes

2024-03-08 22:16:32 UTC

Have you fallen into the ‘rabbit hole’ of covenants?
My newest interview with @AmelieHua
https://bitcoinmagazine.com/technical/an-interview-with-polyd-the-rabbit-hole-of-covenants

2024-02-08 23:13:33 UTC

- reply

@ursuscamp just dropped his CTV playground
https://ctv.ursus.camp/

2024-02-07 19:19:43 UTC

- reply

Here's a diagram of the splitting in a payment pool. I don't remember which reference I pulled it from.
https://image.nostr.build/42a56800ec9a44519e77bc0f31f8c24fe7be81c5c087ab17b549db42da344e73.jpg#m=image%2Fjpeg&dim=1080x626&blurhash=i6SigQM%7B%7Eqt7xuoft7xuIU%3FbM%7BD%25ofM%7BWBj%5Bj%5B%25MIURjayt7%25MWBRjofWB_3ofRjofWBWBWBWBj%5B%3Fbt7t7ayIUj%5Bt7WBWB&x=798c91dd2ca084c01188221c54b9224908ddf482201dadda342a77d33ffabf9b

2024-02-07 19:01:56 UTC

- reply

So depending on what type of Template you're doing, you may to do something to mitigate someone stealing your funds, think Ark and its ALTC's. For Timeout-Trees, the casual user just always withholds their signature. For stuff like lightning channels, or for CTV, the cold channel model, the optimistic path is the keypath spend between A/B and the pessimistic paths have CSV to mitigate stealing. In the more basic templates, this type of security isn't really necessary especially if you're the sole recipient. If you have a basic batched payment pool, what you can do is make alternative paths for if A/B/C want to individually withdraw their UTXO while the other parties are split off into their own shared utxo
Does this diagram for Cold Channels help?
#nevent1q…7zwj

2024-02-07 14:26:45 UTC

- reply

There's a bit of a confusion between the various proposals and CTV itself. Its job is to be a TXID lock and there's not a large design space for that. None of them are competitors to CTV. In fact, CTV has no competitors at all. It's constrained to a primitive and nothing can be added or removed. Jeremy had been working on a few proposals but dropped them in favor of CTV.
Post CTV and we have basic covenants in the market, we can better determine whether we wish for OP_VAULT or OP_CCV (matt). We'll also be able to better analyze whether we want TXHASH or TEMPLATE KEY. In both cases, it would best to have a primitive that acts as a keystone for all future upgrades.

2024-02-07 08:26:00 UTC

- reply

Salvatore mentions it here
https://twitter.com/salvatoshi/status/1661722124610949121?t=_8tNVadpnEo8Dk0vTgyOBQ&s=19

2024-02-03 23:17:13 UTC

#RubinsReubens #LNhance #CTV
https://image.nostr.build/8e0fc019e684f44dcb0ddf89ee756d3fd90195c04f8e3f6fead36e413e4aabb2.jpg#m=image%2Fjpeg&dim=479x227&blurhash=ZEPFT6%25f%7DrIpv%23t7r%3DtQWV*Kt6RQaxM%7CayR%2BkCS%7E%40ZRjD%2B%251tQj%40tQRktRtlWXIpofXRWWs.aext&x=08204e728adc9d458849e417391ecf93406f75469bfada1ae137759b6465bbff

2024-02-03 17:50:45 UTC

- reply

So in John's Timeout-Trees paper, he straight up murks me. "Yeah, scaling to millions of channels with using basic covenants is cool and all, but that's not _real scaling_, we can do billions" 💀. Problem is I've been having to discuss these ideas with training wheels on to help people get the basic concepts down.
https://image.nostr.build/a2f46347c7337ae12080c4218459c17001ea18b5899504ffc6632e99406f5780.jpg#m=image%2Fjpeg&dim=720x154&blurhash=H8RfnIE0%7Eqof%3FcWB%3Fbxu%25MR*xuayM%7BxuWUayWBt7&x=76335bc4f21529477b683ffcb63883019cf89eda8048922db8b056274340d364

2024-02-03 17:16:37 UTC

LN scaling covenants (Timeout-Trees); 35 pages.
https://github.com/JohnLaw2/ln-scaling-covenants/blob/main/scalingcovenants_v1.3.pdf
LN tunable penalties; 17 pages.
https://github.com/JohnLaw2/ln-tunable-penalties/blob/main/tunablepenalties10.pdf
LN efficient factories; 13 pages.
https://github.com/JohnLaw2/ln-efficient-factories/blob/main/efficientfactories10.pdf
LN factory optimized; 30 pages.
https://github.com/JohnLaw2/ln-factory-optimized/blob/main/factoryoptimized13.pdf
Resizing Lightning Channels Off-Chain with Hierarchical Channels; 37 pages.
https://github.com/JohnLaw2/ln-hierarchical-channels/blob/main/hierarchicalchannels_v1.3.pdf
Watchtower-Free Lightning Channels For Casual Users; 25 pages.
https://github.com/JohnLaw2/ln-watchtower-free/blob/main/watchtowerfree10.pdf
Just a little light reading 😭
#LNhance #CTV

2024-02-03 05:17:02 UTC

IYKYK
https://image.nostr.build/6420d9405410107d086c516090ad55e5b7ee26384e17047fe2114e46185d0455.jpg#m=image%2Fjpeg&dim=577x432&blurhash=%236FY.98wPqyE8w%5EjNbDjMw00H%3FMxx%5DV%40tSoeWAbH*xL2%2BZ-pEMI%3Bt7-%3BX8%24%2Bt%2CyDr%40InVrV%40t7V%4000%25gD%25D%25%3FbkCVsM_t7%5E%2BxGV%40Rjt6t7bwNbSh0K-qozIU%253RPozR*s%3A&x=3ce3107cd6de5b588c2b4a0747a56946276429e936d991aab8ecd21fd41fb705

2024-02-02 21:58:33 UTC

- reply

No one can 🤣

2024-02-02 20:55:29 UTC

A Flock of Ruebens
#RubinsRuebens #LNhance #CTV
https://image.nostr.build/cd45df8b0067668183300738684d4529066bf5010894ad89a7f0e22d58bd5995.jpg#m=image%2Fjpeg&dim=1024x1024&blurhash=ULIgZp%5EiAMWAp%7B%252%24M%3D%7Cveo%24%235TKk%3DKjITR5&x=d964698c803f88e9871cb22fc322d9252ed7842b5c44f84fc85eea641f9d754e

2024-02-02 05:55:28 UTC

Let me be absolutely clear. If your proposal allows for full DEX's to be built on the base layer. IT AIN'T HAPPENING.

2024-02-02 03:14:14 UTC

- reply

Great one 😂. Memetics are stronger. It is a mind virus after all ;). Try this one on for... size. (I'll see myself out now 😂)
https://image.nostr.build/b02755887f31fe9a23b00bc088b9f95d417aa839c0cc1deb388ec21709ff93c5.jpg#m=image%2Fjpeg&dim=1024x1024&blurhash=UQH.4v-o_NNx_N%252x%5Doz9GofIBaeT0WXnhsn&x=dba15d5cc47cb723e0fe2f473c80dd8a8d62eafdfcc9b766aec25a772dc07e12

2024-02-02 02:07:47 UTC

Captain Ahabread: Searching for Moby Dish
#RubinsReubens #LNhance #CTV
https://image.nostr.build/0c7b56ae0932baf2c73861bdb6e61ec1dc49bc3d0e8be678fc25b7256a256477.jpg#m=image%2Fjpeg&dim=1024x1024&blurhash=UT8%3F2RyDK%2CIoysslTeT0gNadozo%23TeV%40s.sT&x=a16aac4bb2f55572768201ae691c5135fc91f9db373a0c4aaa283ceed581ef87

2024-02-02 01:57:01 UTC

- reply

#LNhance #CTV
#nevent1q…ng43

2024-02-02 01:50:48 UTC

The Cosmic Deli
#RubinsReubens #LNhance #CTV
https://image.nostr.build/6e21ea93f1a9a96f72d3d44daa74f146958b9072524f5462001070b6cf71a096.jpg#m=image%2Fjpeg&dim=1024x1024&blurhash=U5F5z89bL%23%7C.8w15GZ%24%2500rVMa9%5EO%3F%7EB%5Ek%23R&x=aa3c3535f3e8cbd175f9ba29b87116bdccad83371228b361017f179a3cad4305

2024-02-02 00:47:11 UTC

- reply

It's not about the software itself. If the market was ready for it, it'd be ready in a week. The problem is the market needs to learn what it desires.

2024-02-01 22:42:34 UTC

- reply

I see it similarly to Linux Distros, use Core (compare it to Debian) and from there, various flavors are made. Most security related patches should always go upstream to Core and disseminate from there. Soft forks are bit of a pain points atm, Core has said they're not dealing with soft forks anymore, consensus has to be found elsewhere. So we've been trying to figure that out for the last few years

2024-02-01 21:02:57 UTC

- reply

Here's the BIP for Template Key
https://github.com/reardencode/bips/blob/bip-template-key/bip-template-key.mediawiki
Yeah, I'm not the most familiar with how best to do fees yet but I think Sponsors might be the best way to go, i'd much rather make explicit primitives for everything instead of trying to it perfectly via the covenant mechanism.

2024-02-01 18:59:19 UTC

- reply

Thanks

2024-02-01 18:46:30 UTC

- reply

Txhash is CTVv2. It would allow you to have more flexible fees and control what happens with the committed tx's. The problem is it can be designed a hundred different ways, and I've lost confidence in the developers who are pushing it for multiple reasons. The first being, they don't actually understand CTV, they see it as "limited" because it doesn't deal with sighash flags and sets everything in stone, so they're trying to fix a problem they don't understand. They try and say that CTV is flawed because it uses CPFP more often than RBF but they don't realize (because they don't understand CTV trees) that you can't RBF in those situations or it breaks the trees because the TXID must be immutable. Another big red flag for me (besides the fact that theyve been nacking CTV for years and not producing any code to replace CTV) is that they see zero risk concerns for behaviors that txhash can do such as TXHASH+CSFS gives you drivechains and MEV. The MEV can occur because of the exact flexibility that they desire from txhash. They're also not even aware that CTV has its own upgrade path, Rearden has made one called Template Key. The difference between txhash and TK is TK is a single byte mode operator while txhash relies on multibyte sighash flags. They have zero self awareness and honesty my patience has run out with them, I am finding them to be intellectually dishonest at this point.

2024-02-01 15:55:11 UTC

- reply

🫡

2024-02-01 15:53:47 UTC

- reply

Yeah, vaults place restrictions on your corn. NACK. 🤣

2024-02-01 15:46:42 UTC

- reply

How do you like this one? Tried to keep the Moby theme
#RubinsReubens
https://image.nostr.build/0c7b56ae0932baf2c73861bdb6e61ec1dc49bc3d0e8be678fc25b7256a256477.jpg#m=image%2Fjpeg&dim=1024x1024&blurhash=UT8%3F2RyDK%2CIoysslTeT0gNadozo%23TeV%40s.sT&x=a16aac4bb2f55572768201ae691c5135fc91f9db373a0c4aaa283ceed581ef87

2024-02-01 15:44:46 UTC

- reply

Lightning sir?

2024-02-01 14:46:46 UTC

- reply

I'm curious too

2024-02-01 14:45:28 UTC

- reply

Ok. You boys ready for the sandwich memes?
#RubinsReubens

2024-02-01 14:32:25 UTC

- reply

Good idea. I'll start adding hashes

2024-02-01 12:36:07 UTC

- reply

Bit of a chicken and egg problem, don't get much engagement so don't spend much time on here. But I'll try and do better!

2024-02-01 09:43:08 UTC

- reply

I wish I had more visibility on nostr. I get pretty much nothing on here when I post content

2024-01-30 21:45:36 UTC

- reply

That’s all for now, I hope you’ve enjoyed this glimpse of the medium-term future. It’s probably a few years away.
In my next thread, I plan to show ideas for more advanced tree usage: that’s the really hard design space, but what we’ll all end up using if we scale with covenants.

2024-01-30 21:45:14 UTC

- reply

It just needs to know how to get from the UTXO on chain, up to your leaf in the tree, and how that leaf can be spent.
That information lets Phoenix verify funds exist and are ours. It can handle the technicals in the background.
The user doesn’t need to manage them directly.
https://image.nostr.build/6cba0402516dd38961b6c5b5fdbd09d424321afbdfc2e2cdc799ee7b2f82237f.jpg#m=image%2Fjpeg&dim=887x1920&blurhash=%5B13bw4t700RjTEWB-WofDjWU%3Fuoyv-ofyVR%25%7EqWB9rofx%5BbGxbj%5B%25%7Ca%7Bm%3AayEJWB%3D%7Dj%5B%3D%7DjuSvWU&x=d66683e97ebd450d02660a7aca74c3c55dacdf0d4e346961cd047a196fa95537

2024-01-30 21:44:29 UTC

- reply

Covenants’ superpower is scaling. Payment trees, where many users share one UTXO without trust, are the way - but very hard to visualise.
Here we tell Phoenix about a cold channel it owns *inside a tree*. Once standards have been developed, it's all just data to copy-paste.
https://image.nostr.build/fa83f8747e1899d9c3285410f6a624abd7bb9ec2a62f0e9b67311a5b355b17b0.jpg#m=image%2Fjpeg&dim=893x1920&blurhash=%5B24_zxIU8_M%7B0Jof%25Mj%5B%25NM%7BxuRj%3FbWBoyWBD%25RjxuWBt7WB%25MWB%7EXWBNFayDiWB%25gWB%7EWofIUj%5B&x=7ff58dc9abddbc418aaf98665387d98fd06606dd1de51341043b27b0eaca093d

2024-01-30 21:42:24 UTC

- reply

If we do decide to exit, there’s a time delay in case WE’RE trying to steal - the LSP gets time to respond. All this involves an extra on-chain TX, with fees.
In this case, we never told the LSP about the channel, so even now we’re at no risk from them, even if they’re evil.
https://image.nostr.build/05bd5fc19735f8cbed37c4ff116ba14c66bdb43987ada77c1d89b4d7515c9f7e.jpg#m=image%2Fjpeg&dim=887x1920&blurhash=%5B142SI-q9FD%25oxofkCR*ozInIUx%5DMxR%25-%3Bxa%7EqxatQRQ9FW%3A%3FvoM-%3BR%25oft7D%25ae-%3Bof-%3BWCIVWo&x=78669d092ce5e166857865ef362cc0607502b94373323840207762878eaf2fca

2024-01-30 21:41:30 UTC

- reply

But if the LSP is not responsive, we have a choice to make. Thanks to CTV, we have an escape on-chain: it’s what makes cold channels viable. But there are costs.
We still haven’t actually told the LSP about THIS channel, so funds are still not hot. We could just try again later.
https://image.nostr.build/a01bd9b8c026ca076d34089f0fa3164249c8e237900213a3239930167158f5b8.jpg#m=image%2Fjpeg&dim=887x1920&blurhash=%5B35q%40bkB0KfjR6fktkay0JWU%252of%25%23bGw%7Bj%5B_NofROWBRjWBt7ofw0WBOBofjEf7tRWBxbjuofjt&x=826e98411946268197fedc474025a57632338ec8b27531f9e441c4ad7ca84848

2024-01-30 21:39:24 UTC

- reply

In the "activate reserves" screen, the app keeps a log of all the cold channel deposits that have been made but not yet activated. At this stage, everything is cold and the LSP counterparty is not aware they even exist. No constant vigilance: they're as safe as any other address.
https://image.nostr.build/57790814618a6e6fb255bebf8778475732e9831c3366703a1dbc4e7babf0725a.jpg#m=image%2Fjpeg&dim=887x1920&blurhash=%5B142SI-q9FD%25t5ofofWBt8InIUx%5DMxRj-%3Bt7_Nt7tQRQ9FbF%3Fvsp-%3BR%25oft7D%25WB-%3BoM-%3BaeMybF&x=80e635948a916d9e94932f139253ca9104a747df5df45af2b76c7331c93d4086

2024-01-30 21:38:44 UTC

- reply

In this UI concept, cold channels you’ve made but not used yet are called “reserves”, to suggest that they’re available but not yet included in your spending balance.
To use one, we have to activate it - which makes it no longer cold, so we shouldn’t until we need it!
https://image.nostr.build/fc091c35b6acfb9c3b800ffc659af4155da713ccd5b707f6d3087df94d4e17cf.jpg#m=image%2Fjpeg&dim=887x1920&blurhash=%5B13u%24S%25z9YEJ%25LoyxuR*%24-MenTw%7E8%7BRP%3Fbxb%7EqpGpHSwDiXR_MoztRRQxHxaIUV%40%253oM%3FvoLD%25Rj&x=4c8d62c1da5f287c68ca9ce653a77934f85a2e505b15164b1482d2d034e39343

2024-01-30 21:38:01 UTC

- reply

Receiving into a cold channel is just an address on-chain, a CTV construct involving your key and public info from an LSP. Perhaps you get 10% of every payslip sent to these. Since they’re cold, there’s little risk.
The sender doesn’t have to do anything special, or even know.
https://image.nostr.build/949e15d12458375c5543f1a075f92d564855c9de35e86ff71966ff8c5a6603a1.jpg#m=image%2Fjpeg&dim=893x1920&blurhash=%5BGB%7CKZWB00M%7B%7Eqj%5BD%25WB9Fay%25Mj%5B00WB%3Fbof4nWB%25Mj%5Bt7j%5Bj%5Bayxuj%5BWUayIUfQxuWBxuj%5BWBj%5B&x=8a2b6d96c4a8f31f82240a9094778a088095273d70eee5e6fd97d346b4527c0c

2024-01-30 21:37:17 UTC

- reply

Here’s a link to the Figma demo to play with it yourself. Or, keep reading for screenshots along with explanations of what’s happening behind the scenes.
https://www.figma.com/proto/o4sxu0rEIR1zmletrxtXRn?embed_host=twitter&kind=proto&node-id=2-60&page-id=0%3A1&scaling=contain&starting-point-node-id=2%3A60&type=design

2024-01-30 21:36:19 UTC

- reply

We’ll use the Cold Channel construct, see below. Have all your funds LN-ready but still cold - without counterparty risk until you decide to start spending!
(With hot funds, you must constantly watch for theft attempts by an evil channel partner and react)
#nevent1q…t89l

2024-01-30 21:35:07 UTC

In Covenants 101 we covered the technical basics, and in 102 we outlined some example use cases.
Today we’ll look at a demo of what really using these might be like for the average person.
This is what Phoenix self-custody lightning wallet could do with CTV.

2024-01-30 21:32:48 UTC

- reply

The most complex but powerful use, bringing all the concepts together, are tree structures.
Each switch can have MANY alternate paths, not just 2. All agreed in advance to build the address.
Each branch can be another tree, any leaf an LN channel. Exits may be into other trees.
https://image.nostr.build/d39632d9f25e8824f88425416e305eab7b6ef42a9224c42b24c044e07c262b67.jpg#m=image%2Fjpeg&dim=960x540&blurhash=iGJHs%240200IpIV_1oI-nDj%7EVIVIVM%7CWBt6s%3AoeRj00%3FY%3FZovxtM%7Ct8RnxuIUV%40M%7BaeWCWEogt7xt01%25M-pxtxtIoR*M%7BoL&x=d496f007562aced8ace6ef07936c9b47069d36866202312612a2f822a4b9c776

2024-01-30 21:32:18 UTC

- reply

Here is where bitcoin enters the next dimension.
We will build on all the topics we’ve learned so far and combine them to (theoretically) scale self-custody to billions of users, whilst keeping the promise of only using small blocks.

2024-01-30 21:32:00 UTC

- reply

It’s more efficient than regular channels, AND the incentives flip.
Receiving on-chain to a cold channel gets a FREE OPTION to use LN, yet no less security.
If there’s an issue, you’re no worse off than today.
Result: many more sats on LN, & so more transactions move to LN.
https://image.nostr.build/f9fd33773a851e375ef91384b005fcddd297a7be2743da20548f69518991c37c.jpg#m=image%2Fjpeg&dim=825x540&blurhash=r67xBu.5RzRjVtRRIUt8xtpPjKRCaixca_V%5Dk8WBDSH%5DIBodx%40tPf%23WXayr%23bWR%24oxoxa%23k9WEf6tGyBtkogaQRQt7WARj%23xWANEk8k7j%5BbXaija&x=3329ea1a5da027f809f762a80c17fb860055934d498ac379894bcc18adbee1a3

2024-01-30 21:31:08 UTC

- reply

The Cold Channel construct is a receive address, with spend paths that make it usable as a lightning channel with a chosen counterparty.
When you reveal these paths to them, it’s instantly ready to use - WITHOUT another on-chain transaction. You can now send the funds over LN.
https://image.nostr.build/b56d3ced750e49f4eb52c1b8593031894d6c144c5ad404556c5636b5381cf0a0.jpg#m=image%2Fjpeg&dim=960x540&blurhash=iIGR%7C-0N9b9bbb%251V%3FxZjE%7EVIWIVM%7CV%5Bocj%3Ft6oe00%3FYxp%25Lj%40NHt8WEj%5E01xZsls.jaRnt7bIbIxubHofayWBs%3BfiWBRj&x=49ba0becf3db3d0e8819a2955b8a554b8d9bee2d2bf00ed87012c8a40f161ce4

2024-01-30 21:29:25 UTC

- reply

Many useful structures can be built with that principle: CTV fixed path, plus optional escape path using a key.
If the key path is a multisig, we can involve more than one person. It’s a shortcut if everyone agrees - and a veto when they don’t.
https://image.nostr.build/e63cb3f6ebd1c47e844013406b7a793df9e49e87be7b427f5ee335f080c349bb.jpg#m=image%2Fjpeg&dim=960x442&blurhash=Z697V11PMH%24y9%2B-69FNe-hR%23%24%24NhRlekWCxus9Wb4-%3DEESNe-ONy%25Njsof%7EqIrMvt3Nht6RjR.s*&x=41eee0b218e83f570ddd3154e4aec5283406da22f31fc87e4f6830ac434d8bda

2024-01-30 21:28:57 UTC

- reply

With CTV we can make a secure vault that’s still flexible.
Our vault address may ONLY CTV spend to a switch address.
That starts a timelock: After 14 days, it can be spent to anywhere.
Before then, it can be recovered instantly, but ONLY to a pre-defined address.
https://image.nostr.build/1f286fd1ec5927b2e2d706b807b8ea2ef59f0bbe46dd85a732ebb5c2679dd472.jpg#m=image%2Fjpeg&dim=960x540&blurhash=iEEfD%5E00-g%3FWIqWGxWRj4p%5E%2BD*RPs-RkWCocoyM%7C00%7EoItI%5B%250j%3BkDt7%25L01%252M%7DNIn%24ayt8kB%25K%25LxaRjofa%24ocf5V%5Bof&x=2381b9c7fa16ef917243a96680ca775a8d5939c92ab20341e431535aa5f369f0

2024-01-30 21:27:59 UTC

- reply

A simple useful path switch idea, usable today without CTV, is fallback for multisig.
Build a script with a second spend path, where after 2 years, you need fewer keys to spend.
If you haven’t lost any keys after 23 months, just send to yourself to restart the timelock.
https://image.nostr.build/bebf08457467b8b1f01e46dcb9dcdb4931ce6e8512e411bc5901a358da951545.jpg#m=image%2Fjpeg&dim=743x540&blurhash=%23FFYoc0202_0IT%5E%2501s%3A%25M%3FGMzD*n%24WAxtNGf%2Bxu00%7En%3FZE2%25MIW%5E*M%7CIU9Gs%2Bs%2CRoogR%2B%252k9Rj-%3Bf%2BR*oKM_RjWCofxakWxuxaRjM%7BM%7Boft7jbxYIVWBs.WCt7R*t7bI&x=d4b2c0c16589064413e813976854a093a59678bc9cb4e876ec229a0ecf06925c

2024-01-30 21:26:43 UTC

- reply

We covered in 101 how addresses are generated from spending conditions. YOU pick what can unlock YOUR coins.
You can also use logic to give multiple options: spend this way, OR that way.
Almost all addresses are scripts. Here I’ll nickname multiple-choice scripts a “path switch”
https://image.nostr.build/436f333717eede71268890744b0f203577d11c762eb117a00334e8b1b32d3461.jpg#m=image%2Fjpeg&dim=960x540&blurhash=iB9tJuITMxaen%2B%7Eq00IoozxtRiWBaej%5Bt7M%7Cogj%5D00%25M%25MofWB4n%7EqxuRjD*x%5Dt8ofWBIU%25MRiae_3RPIUV%40t7-%3BD%25M%7Bt7&x=98b515f6a7cc7be720dd0703cf9755623d4f16372a7214184a46176da0edb026

2024-01-30 21:26:03 UTC

- reply

We will build on concepts from Covenants 101, so make sure you’ve read and understood that first!
This won’t make sense without it.
#nevent1q…mqjd

2024-01-30 21:25:03 UTC

Welcome to Covenants 102, with a focus on CTV still.
In this thread I’ll walk through three clear use cases, impossible without covenants. Each improve bitcoin significantly for the average user.
We’ll build up our understanding for the last, most powerful one: payment trees.

2024-01-30 21:24:36 UTC

- reply

Wait: Don’t we have to mine this huge pile of Tx eventually, for everyone to REALLY get their coins?
If we collaborate, NO! We can build alternate spend paths. But that’s a whole thread.
You now understand covenants 101: commitments made *without always touching the chain*.
https://image.nostr.build/af8c073839e0d3d94b51b9ad0c7622e221238d43649cccc6e67d7d9c3590875b.jpg#m=image%2Fjpeg&dim=1118x668&blurhash=i8BzB%7D%3F%5B00DPVt9ZIA%3FH%25N%24%3AQ%3FDiNYScMyRQ%25M%25fEbti-pt8s%3Bs%3Ax%5DWCMx00DjWB%3Fb%3Fvt8spM%7BE0IURjsoxu%25MxuRjIUMx&x=63b4dcf0ac4f4e43b44c443a7fd3746da00b765dbc08b483ab0bdd78446f32c7

2024-01-30 21:22:41 UTC

- reply

Instead of each L1 Tx being one ownership change, we can plant a whole tree full of many users, all sovereign, but only using 1 UTXO of block space.
If the leaves were lightning channels, you can even be spending sats freely - only updating the tree rarely for channel closures.
https://image.nostr.build/0c861e00fd55294328c204d5196b453fded7ab31a4d25b585ede30296fab0060.jpg#m=image%2Fjpeg&dim=1106x671&blurhash=iD9asXxaRRoyMzx%40MyW.RkD8Vvx%40V%5BoxozaxbFay%3F%5BtQV%5DkBV%5Boze%3AWBaeMhbaoMWBoxnmW-WBa_i%25btjbaykUjIX5e%3Aoe&x=e0dde6b60451a24531945c751fc8a5a8b97a9e9c19b1977e724c94b467225953

2024-01-30 21:22:03 UTC

- reply

What if each layer paid many people, not just one?
We can go as deep as we can coordinate in advance.
When Alice makes that ONE payment on chain, EVERYONE in the tree is paid:
The guy before them CAN’T take coins back, and keyholders can all exit whenever they want.
https://image.nostr.build/1e7a2cf5b13e457fd491933dd65b873816298b39bf3d58b047ab97b91b71fbf6.jpg#m=image%2Fjpeg&dim=1192x669&blurhash=iHEo*%2BV%3BX9E3RQxWxuR-4n%7EWR7RkozWnoft8NGD%259%5ByDxZw%5DafNLSOV%3Fs802M%7D%252aJt7R.IUsm%25MDingt7R-R*s%2CjDozkr&x=12493c317e26b3f4a521ca6b8aa397d505f8b0da47e20e9b127862271d7b90aa

2024-01-30 21:21:30 UTC

- reply

We burden the chain with only 1 transaction, yet get more than 1 ownership change, or said differently: irreversible commitments.
What if Charlie did the same thing in creating HIS address, with someone HE needs to pay?
What if they did it too?
https://image.nostr.build/c289037b502e0309303bfb19fac318ed68701e7faed8da6545431738f289635e.jpg#m=image%2Fjpeg&dim=1193x669&blurhash=iDD9q%3B_09ZIvRQs8-%3BNH00%7EDnAIWozbXofxvM%7B9YAXpb-owIRkNyNIVsw%5B00WG%251s7ozR.IUjE%3FH4mxBt7NIWXs8ngozp0&x=17ba9658e51d6b21db07c5af96eff67e8f5dc2107a7d18d01d2d5da510978810

2024-01-30 21:20:54 UTC

- reply

If you choose to ACCEPT payment via CTV, the payer needs to pass you the Template for every step between your coins and the mined Tx.
That’s what you need to fully exit if you want. We always have to store data: private keys, channel states for LN, now spend paths for CTV.
https://image.nostr.build/74652db29a123422f4fb89df01c07ca7cda6bb20f13306fe43a5f0073ab9c3b1.jpg#m=image%2Fjpeg&dim=958x670&blurhash=r5B3%24gL30A%5EN00r%2CIs4p%25g*f4ZEl%3FWIBrpOWXSxu1X.0%3D%5D9H%3Fd%25hRQxbIU00Mc%24_S%25%3FvtTxZ%25LIUbxowjYa*WTV%40oga%5EV%5D%3Fw-%3AxZRSD%24E1WFV%3Dxu&x=368e9f7ce313fab67d6af1690bbb7169708c83ee74119c9a655bbbd077538e81

2024-01-30 21:20:17 UTC

- reply

If CTV was live, Bob can make his address key be a signed but unbroadcast Tx sending to Charlie’s address. Nodes will reject any other spend as invalid.
If Bob hands that Tx to Charlie, he can SEE Bob can’t spend them differently. And pay himself out any time, without asking Bob.
https://image.nostr.build/b73b9aa2513cac938ce22752e2e55e8d34852c25639fe7123bc217393b75d98f.jpg#m=image%2Fjpeg&dim=1192x669&blurhash=iDD0AP%7ES4%3AI%5EMxxa%25LNL00%7EErZIWtRR%24t8t8NG9FFZcE-.rqRnNeNLVsxC00NN-Ui%5DtRNGIVjE%3Fa8%5En%23xuNHa%24nhs7ozks&x=87fb386b20b37aa79c7066ff1b00c4cb7da3de3e8e7456b81827a21a9bb9a770

2024-01-30 21:19:36 UTC

- reply

OP_CTV, Check Template Verify, proposes a new primitive added to the family: check that the SPENDING transaction, hashed, matches one we defined.
It’s kind of like using Tx data as the key for the lock, instead of a private key. And if YOU build the address, YOU decide the terms.
https://image.nostr.build/d604b741a0ceef68dec454864105f8bf82d28d5f58b13df3f44d1876a0f1c591.jpg#m=image%2Fjpeg&dim=1192x672&blurhash=iBBWY*8%5EM%7Bxv4ox%5E00Rk_2%3FbD%24ozt7aeoLayofR*00Ip-%3Bs%2CxZRO%7Ept74oWBV%40t7j%5BWXRj%25MRjRi%7EVemITbbkXkXD*NG-p&x=d26abb0dd8bb9c4b41f29adb2b9205c603d82bde91a0338f31f6eb22e7f2a66b

2024-01-30 21:19:02 UTC

- reply

You build a transaction with the To addresses, attach your UTXOs, and show whatever’s needed to unlock them. Then broadcast.
Before it’s included in a block, Bob can’t be SURE he’ll get the coins. EVERY ownership change MUST touch the chain to become immutable.
https://image.nostr.build/b18f598c21dd8006048309ad4beea8bc209af7c4b04f7dee240f0ccf7dbc954f.jpg#m=image%2Fjpeg&dim=1191x670&blurhash=iADS%25P_059nmwuXn009bM%7C%7D%5EMgN%7BtQagf94mj%3BWB6%7Cl8%24LMzOai%5E%3DtxBkD00rt%2C%2CWTOGIU_4W%3DR.4TxVf%2BM%7CxBS4k%5BS6xs&x=88f9bcb0507eadb4359a919f44ced66be1f2ddf1056a5bda5e36636e8970111b

2024-01-30 21:18:29 UTC

- reply

There are other things we can use to make our locks: extra keys, relative or fixed timelocks, & logic to combine them. The address encodes it all.
(Technically, they’re all actually scripts - the different functions used inside: OP_CheckSig, OP_Multisig, OP_CheckLocktimeVerify…)
https://image.nostr.build/2b29d24f553963c408378974075fbc065d803f3d075c9e52fb4c64ef3a5912c5.jpg#m=image%2Fjpeg&dim=1194x671&blurhash=iICZU%7BfP9Ys%3AD*xu009Z%7EqMvWBbXjFt9ofxvXSRjs*ayWUoKj_t7bJNGWA%3FbofV%40WBNHWBD%25kC%25L4mjv%252WBkWRj%25g%253IT&x=560797a2678a79e78834b14a9e958e2256fca7d5d99a492bf8645efa771af48c

2024-01-30 21:17:54 UTC

- reply

Addresses are built from the spending conditions YOU want for YOUR coins. You have a key, you define a lock that it opens, that IS your address.
Coins (UTXOs) sent to the address must be unlocked to be spent. You defined the lock, you decide what opens it, nobody else.
https://image.nostr.build/fca005bb5bb015cec41091852706d2c29ca56e2a585c365876705e1199f28866.jpg#m=image%2Fjpeg&dim=1193x670&blurhash=iB9Z%7D%5BR4MwV%40R%2B_401E2bwxaV%40j%5BayWCogNGogay00p0x%5Dozsm8_%7EV-oi%5EE1tRa%23oes.V%3F-pRij%3F%7EWr%3BMxWBkCx%5EE1E2g3&x=0074ba584c939245de6642f0af58fb03a58caa071c164670b1edbee8f2a5deff

2024-01-30 21:17:12 UTC

Welcome to Covenants 101, with a focus on CTV.
What are they? Is this an attack on bitcoin? Can the government lock up all our coins?
Without an accurate mental model of what's actually going on, it's hard to reason on what they can and can't do.
So let's walk through it. 📩👇

2024-01-29 23:10:21 UTC

3 hours
2 views
1 like
Is nostr dead?

2024-01-25 14:25:45 UTC

Vincent Van Dough is available for grabs.
The cost is your time.
Read up on why we want layers and how CTV and CSFS (LNhance) will provide these delicious layers.
https://image.nostr.build/a36b51830105c1417b4226e6373cb0c1377a84f3d74cf73a05b0917571943ee1.jpg#m=image%2Fjpeg&dim=1024x1024&blurhash=UPF%25Sk%25L7%25Ei-rxYO%5BV%40cDRQrBxYPVSjVsaf&x=7540dd083c230fdb577709023626a2597a2c30566c910ca5dbf79886cbd6eb51

2024-01-25 01:30:09 UTC

- reply

You're the one telling me about what central banks do and how that impacts whether or not you consider to be custodializing something. "Base money is based on policy" wtf is that

2024-01-25 00:49:18 UTC

- reply

Here's Calle's words on the subject of eCash being "noncustodial"
https://image.nostr.build/055504923ba1a485f94e35eecf60d6752b388eed6e4ead23943fe9fc615730b2.jpg#m=image%2Fjpeg&dim=1872x588&blurhash=Q9RW0eD%25%3Fbt7-qxu%25Mt7%25Mt7fPf6t7RjjZayayj%5B%7EqRjM%7BoLRjofRjofRj&x=7e82f301744a08b6fdc82be3da04f803c9e14b2bca3de6ca96e873de28dfb280

2024-01-24 23:32:17 UTC

- reply

There's a reason we're Bitcoin maximalists and not fiat maximalists. There's a reason we don't depend on Trusted Third Parties. This is about cryptography and hard money, not Trust Me Bro. I don't know why you're trying to use fiat methods for why you should be doing certain things on Bitcoin. Lose the fiat mindset.

2024-01-24 23:15:33 UTC

- reply

How did that work out for the Weimar Republic?

2024-01-24 21:26:19 UTC

- reply

Gold coins are. Paper isn't. Why do you consider IOUs to be legitimate? You're not actually holding *the thing*.

2024-01-24 17:34:47 UTC

- reply

That's not something I'd call self custody then. I have a piece of gold, but it's inconvenient so I swap it for a note backed by the gold. I'm still "custodying" the note but it's not actual self-custody and just fugazi.

2024-01-24 02:15:14 UTC

https://image.nostr.build/b4fb051cdbafc476b7410a988a0292f7d74a0349816dd4e087b301ff562d0296.jpg#m=image%2Fjpeg&dim=640x480&blurhash=%23DFYS%2C0e4m%25hXAM%7BaKs%2B%25M9a%25MNLskoLt7NGRjfi%24dxvI%5DM_t7W%3BRikCWB%7EqIU9Fx%5D%25LNGV%40Rjt8%25LNHRj%251s%3AogWCM%7BofRkbIjYxYt7oeRjW%3DoK%252WBNGj%5Bs%3AozWBRjWX&x=c68fe8c4e25bde7024f1c413665adbf703a75da4376938a6b53fae0291d47870

2024-01-19 13:54:10 UTC

- reply

So Rearden went through the process to creating a version of txhash that was CTV+APO, here's a table that shows what's hashed.
https://image.nostr.build/0b4c63b7cbeb1ce4f43b2c91465037fb22ce02edc8ed4be2b224b5369b33a5a1.jpg#m=image%2Fjpeg&dim=1034x1696&blurhash=%5D45r3%5D_4WBRjIU-%3BofM%7BRjof%25NofM%7BRjofxut7j%5Bayj%5Bt7t7ofRjaya%7Doft7off6Rjayt7ofWBayj%5BoffkjtWAfQj%5BaefQ&x=aae7b5146327c887b41cecb244d7ab58c602405609a3ceb7f6e46821b15afa5
The script itself should look relatively normal, but there'll be an extra associated 32 byte hash that is used to evaluate the script when you're spending from it.
https://image.nostr.build/b56d3ced750e49f4eb52c1b8593031894d6c144c5ad404556c5636b5381cf0a0.jpg#m=image%2Fjpeg&dim=960x540&blurhash=iIGR%7C-0N9b9bbb%251V%3FxZjE%7EVIWIVM%7CV%5Bocj%3Ft6oe00%3FYxp%25Lj%40NHt8WEj%5E01xZsls.jaRnt7bIbIxubHofayWBs%3BfiWBRj&x=49ba0becf3db3d0e8819a2955b8a554b8d9bee2d2bf00ed87012c8a40f161ce4
The guys are trying to get the minsc branch that supports CTV to compile so it's easier to build PoC's. Trying to look at these clips in bare script is going to be a near nightmare as you can build trees and many exit options. Here Jeremy talks about splitting and evicting a single individual.
https://nitter.net/JeremyRubin/status/1744140391249506504#m
Here's a split and evict for a payment pool
https://image.nostr.build/42a56800ec9a44519e77bc0f31f8c24fe7be81c5c087ab17b549db42da344e73.jpg#m=image%2Fjpeg&dim=1080x626&blurhash=i6SigQM%7B%7Eqt7xuoft7xuIU%3FbM%7BD%25ofM%7BWBj%5Bj%5B%25MIURjayt7%25MWBRjofWB_3ofRjofWBWBWBWBj%5B%3Fbt7t7ayIUj%5Bt7WBWB&x=798c91dd2ca084c01188221c54b9224908ddf482201dadda342a77d33ffabf9b
Here's a payment pool that was compiled in Sapio
https://image.nostr.build/349dc76eb0165335f3bf8d4df81127c8208a250a47cf1fff9cfe54b20eb6c864.jpg#m=image%2Fjpeg&dim=1920x1200&blurhash=r5S%24ovkC.8xuxuofWVRjaexbV%40RikCa%7CWAj%5BayWB_4NGD%25RPV%40ofayt7ofV%3F%25MxuM%7BRjofj%40ofoyD%25W.ofxut7RPozWAae%25NjEf5ofj%5Bjuaeaxaz&x=257179487fff78e3a471c9c728415d83d158cf2c39c3709778311abdfd1bb880
Here's the txhash with CTV+APO by Rearden. He ended up abandoning it in favor of Template Key which is a 33rd byte extension to CTV but it isn't anywhere near ready and needs probably years of bikeshedding to finalize it. He's in favor CTV now then later extending to either TXHASH or CTV as necessary.
https://gist.github.com/reardencode/2aa98700b720174598d21989dd46e781
Sorry about the fire hose of information, there's just so much here.

2024-01-19 00:35:54 UTC

- reply

Makes sense. Still learning nostr etiquette. Here's the nitter links
Covenants 101
https://nitter.net/OwenKemeys/status/1741575353716326835#m
Covenants 102
https://nitter.net/OwenKemeys/status/1744181234417140076#m

2024-01-18 00:04:50 UTC

- reply

Owen made them up for his Covenants 101 and Covenants 102 threads over on X.
101
https://twitter.com/OwenKemeys/status/1741575353716326835?t=cgvZGJoMLv9P5DGPV5Sq3A&s=19
102
https://twitter.com/OwenKemeys/status/1744181234417140076?t=jnW9Wd89NwRT8StZ0SQqxA&s=19
102 covers the more advanced use-cases such as Cold Channels whereas just covers the basics such as Congestion Control. Let me know if these help

2024-01-13 01:06:36 UTC

- reply

I wish I could easily describe the nuances and complexities to why we should continue upgrading, let alone why one design choice is better than another.
APO's design path is final.
"It introduces new key types for the existing sigops with a concrete set of sighash flags that cannot later be upgraded without adding another new set of key types."
Once we had implemented Taproot, it was final, if APO has been included with Taproot, it'd be great, no need of this duplicate the key type + 1 single feature. We can't build off it, we'll just duplicate key types again.
So why do we want APO in the first place? The original design choice of Lightning used it before it was later changed to HTLC's. Implementing time locks was a better design choice because the design scope was minimum and the risk analysis was more concrete. Those were our first covenants, simple time locks.
But here's the problem. We didn't actually create proper channels inside Script. We have this bi-state channel syndrome. We call this Asymmetry. Alice has her version of reality and Bob has his version of reality. And we're agree on the final state of reality when closing the channel.
Our original channels that used nSequence didn't do this, we agreed on the final payment, we didn't need our own versions of the transactions. But it was unsafe. 0-confirm transactions are second rate. Someone could sneak in an old state into a block and there was no way to prevent the theft.
So we restored channel functionality with time locks. This window of time allows us to defer commitments to on-chain and create backpressure on blockspace demand. We extended this to routing and envisioned Lightning as a mesh network on this method of deferring chain commitments.
But this symmetry of channels still plagues us. It creates many inefficiencies and prevents many use-cases because Alice and Bob never agree until close-out. APO allows us to agree on payout, just not on pay-in. This would provide symmetry and reduce complexity of channels.
After almost a decade of research, another covenant type with a narrow design window was finalized, output commitments. I like to call them TXID locks or UTXO locks. And what do you call a group of UTXO locks? A Template.
Check Template, Verify. It sounds so simple yet it eludes even the best. If Taproot and Schnorr Signatures provided Signature Aggregation, CTV provides Transaction Aggregation. Like tapscript, you can build trees with CTV. BitVM has a brother.
Like channels, output commitment covenants opens up a window of time in which people can work together to coordinate and save on commitment space on-chain. I tried to explain this emergent behavior on internal scaling with Enigma.
And Enigma has been quite the enigma to many. Especially with a lot of developers. The problem is we've shoehorned out thought process with only channels and have blinders on. We're always thinking about the single next on-chain commitment, never ahead or behind.
CTV fixes two issues, the L2 exit problem. Withdraw from an exchange to LN. On collab closing, move it to another L2 or channel. You can always defer going on-chain, just keep making Templates of what you want to do. Also, payments can be made without needing 0-confirm.
So why don't some developers like it? They're plagued by the bi-state asymmetry still! But it's like asking a fish to fly. CTV has one job. Make Templates. It can also be extended to either TXHASH or TEMPLATE KEY with no issues. It has no closed path development issues like APO.
So what's LNHANCE? it has 3 BIPs. CTV, CSFS (CheckSigFromStack) and IK (Internal Key). IK is simple, it's a 1 byte substitute for a 32-byte key so it's just a space reduction with no design change. CSFS allows us to defer signatures which will allow us to defer channel payments.
This will fix the asymmetry problem and provide us with what's known as LN-Symmetry. This will allow us to build a network of trees filled with symmetry channels that will probably scale beyond anything I can even begin to imagine.
But I don't need CSFS. I think we should fix our channel asymmetry issue and I think LNHANCE is the right choice, but I just need CTV trees. Templates will unlock so many possibilities that just aren't possible today. The very concept of Cold Channels is so alien. No wonder developers can't get it. I don't blame them at all.
I believe we should continue exploring these pockets of time of where we can defer something essential to us and our means of payment. There is still so much left to explore and I hope we're able to do that. Our signal has become so broken and we can't agree on anything anymore. Let us come to consensus one more time.

2024-01-12 23:26:07 UTC

#LNHANCE
https://image.nostr.build/aaaae96b9b33edf6b84a914ea6c111b952db8b8619c2e246083723d201516b2b.jpg#m=image%2Fjpeg&dim=500x544&blurhash=%7BNJa%3D%23_19u%7EVxVksngt7Im%25gs9D%25XAs*t8j%3Dxb%252t7E1MyxtWBbIx%5Ds%2BRPozxtRkM%7BRkkEs%3AayNIsmjsR-aebcRje.xukDWUaeWBt6oza%7DjYjsRjRlWBWBRjNHn*s%3AWrWBt7WBt7oeRjfij%5BWCoJ&x=b4132558c1a8376ea12b91d8b7e0ef28e4e4d5c621f65648c634d10143b15c8c
https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376

2024-01-12 17:11:51 UTC

- reply

It should look like a relatively normal channel except you roll it up into ctv to hide it. It is "cold" since you partner isn't aware of its existence yet. You'll need to coordinate with them to close it efficiently, otherwise you'll have to deal with the time locks.
https://image.nostr.build/b56d3ced750e49f4eb52c1b8593031894d6c144c5ad404556c5636b5381cf0a0.jpg#m=image%2Fjpeg&dim=960x540&blurhash=iIGR%7C-0N9b9bbb%251V%3FxZjE%7EVIWIVM%7CV%5Bocj%3Ft6oe00%3FYxp%25Lj%40NHt8WEj%5E01xZsls.jaRnt7bIbIxubHofayWBs%3BfiWBRj&x=49ba0becf3db3d0e8819a2955b8a554b8d9bee2d2bf00ed87012c8a40f161ce4
https://image.nostr.build/51dd64446cab2300f34e507e1856ab57c8b892b56a496b6f42eba3a0c8fc4516.jpg#m=image%2Fjpeg&dim=613x813&blurhash=_OPP_wayxuayxuj%5Bxur%3FfQaefQaefQae.SWBfkayfkaybH9tofoza%7Cozayof%7EqayWBj%5BR*j%5BWB_3WBaefQV%40j%5BWB%253aeV%40jZaej%5Bae%25MayayfQWBj%5BWB%24*aybbfkbHfQbb&x=6faeee704d9c5caaafc379aef0a006568dac29b00085fc8f87dd36b856f6d9b9

2024-01-12 15:40:09 UTC

CTV and Cold Channels.
Today in Bitcoin, to make a channel, you must first receive Bitcoin on-chain and then transfer it to a channel with your partner interactively. This is a minimum of two transactions just to open a channel and the channel opening cannot be batched.
With CTV, channels can be hidden inside your pubKey so that when you're paid and the transaction is committed on-chain (can even be batched using only one UTXO), that on-chain commitment is sufficient to use your channel. No need to dump the channel details on-chain.
https://image.nostr.build/9c5674ec45bb1c4b1a84c1c1b7223a6223391c8914639cebc09304e2c9f82616.jpg#m=image%2Fjpeg&dim=819x540&blurhash=r89tP%25yUD*M%7CNZV%5BM%7BxuRRGcnhr%3BoInhWBV%40kWWBHbICbrkURQoybYfRox%5EcW%3DNIW%3DS4oLWCjYayucyAVun%2Ct7V%5BahWAV%5B%7DmR.NKWXNIoeW%3BjFWB&x=860ed55345f9f855729c8bf1dfd19accc63cac0b31f90d19fef23c3a444d4263
https://image.nostr.build/f9fd33773a851e375ef91384b005fcddd297a7be2743da20548f69518991c37c.jpg#m=image%2Fjpeg&dim=825x540&blurhash=r67xBu.5RzRjVtRRIUt8xtpPjKRCaixca_V%5Dk8WBDSH%5DIBodx%40tPf%23WXayr%23bWR%24oxoxa%23k9WEf6tGyBtkogaQRQt7WARj%23xWANEk8k7j%5BbXaija&x=3329ea1a5da027f809f762a80c17fb860055934d498ac379894bcc18adbee1a3

2023-12-27 15:02:16 UTC

- reply

We have two covenants already, CSV and CLTV. they're time locks to control when a tx can be spent. The next basic covenant is CTV, a "UTXO lock", this constrains the TXID so that the transaction is *guaranteed*. This will help us scale via solutions like Ark and Timeout-Trees. My personal favorite is NIC's (Non-interactive Channels), this let's you commit to a lightning channel simply by knowing its Txid + hash. To explain how this would work, I need to withdrawal from my exchange on Friday, I go ahead and commit to making a LN channel with Bob inside my PubKey, and the exchange pays me in their batched tx. Now that I have the commitment, I can at any time, contact Bob to "establish" the channel, with no need of a second transaction.
As for Lyn's comment on how the dev community is split. CTV can be upgraded either to Txhash or Template Key and a lot of devs want to skip step 1 and go straight to the advanced covenant proposals. They've even gone as far as to say that they fear CTV would delay txhash. I want txhash too! But it needs years of more bikeshedding before it's even close to ready. CTV is ready, it's been ready for 4 years.

2023-08-01 13:57:15 UTC

- reply

Here's the one I just wrote, i'd start here
https://app.sigle.io/polydeuces.id.stx/9PHVc0PWHk_skP15_cYOb
My primary paper
https://app.sigle.io/polydeuces.id.stx/bo-iHio5_4iTlvWwXwZ9l

2023-08-01 13:32:32 UTC

- reply

Haha, nice list of projects. You should read my two papers (second then the first), tell me what you think.

2023-08-01 13:30:12 UTC

- reply

Quit being silly, use proper covenants and people will stop questioning Bitcoin.
https://cdn.nostr.build/i/497d9845c02eb8945b338f62a800278da9440c6da435306b490ab4bff5d0e200.jpg

2023-08-01 13:10:31 UTC

I'd like to be on nostr more but it's just a wee bit boring at the moment. No notifs and no real engagement. Where's everybody at? Pull me in.