BREAKING – nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg now renders Cashu ecash in DMs!
No way
Idk what non-equivocation bonds are yet. Im just public note taking from a second pass through nostr:npub1qdcakl75gd7wv0nqmmwrz09ddm5tzl7xj8lq2gclng2qzd8up5yqjpzclt
nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 nostr:npub1emdtsxly9m68m00x206t574jttp65vk0c2m89ms038q047yz7ylqcac9aw or nostr:npub1mxrssnzg8y9zjr6a9g6xqwhxfa23xlvmftluakxqatsrp6ez9gjssu0htc may be able to answer that?
If you re-use a nonce for two different signatures with the same key, it leaks the key.
Imagine a UTXO is encumbered with a script that says “you have to use 7” as the nonce.
If you can spend that UTXO and you sign more than one transaction spending it, you leak your private key.
Lots of interesting applications (especially in multi party settings) where you can make it costly for someone to sign two conflicting transactions
Want to check a merkle inclusion proof *in* your script? Need CAT. Want to check that your script itself was included in the address commitment? Thats taproot
nostr:npub1mxrssnzg8y9zjr6a9g6xqwhxfa23xlvmftluakxqatsrp6ez9gjssu0htc
For op_cat, its purely byte weighted for limits? Like a const somewhere?
It doesnot use the modeling stuff discussed toward the end by Andrew?
nostr:npub1emdtsxly9m68m00x206t574jttp65vk0c2m89ms038q047yz7ylqcac9aw nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8
PS poelstra nostr? 🤔
In the current proposal for CAT (BIP-420), its Just Another Opcode. The check is that it fails if you try to create a stack element longer than 520 bytes.
In the proposal from nostr:npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s , there is a variable operations budget (varops) and if you exceed the budget, your script is invalid. In this model, the “cost” for an operation is based on what kind of operation it is (add is cheaper than mul) as a function of its input length(s).
Finally watched Oppenheimer. Good flick
We covered a lot! 2.5hrs of Poelstra, nostr:npub1emdtsxly9m68m00x206t574jttp65vk0c2m89ms038q047yz7ylqcac9aw and nostr:npub1mxrssnzg8y9zjr6a9g6xqwhxfa23xlvmftluakxqatsrp6ez9gjssu0htc . We exhausted all the parts we could, steel man, straw man, alternatives, status quo, activation, etc,.. hope to get this out tomorrow.
Nostr has the best questions contributed.
nostr:note1u2y79dfrykpmjvjurnffl2eamay28pl9lrssea55a53yy2gnn09s5zhxvm
Awesome conversation. had a lot of fun
I really like how simple boardwalk cash is.
I’ve also got an M3 pro and its an absolute monster of a machine. I love it but it mostly stays on my desk plugged into my monitor. So its more like a desktop machine that I opportunistically use as a laptop.
4 years on, the m1 macbook air is still the best laptop ive ever bought.
nostr:npub1m6yz8nwf0xl5cafjy0kurxn6hs67eleft8h4pj57n4tn4s8c8lgqd2mzj9 gave me a walkthrough of the fedimint module interface at bitcoin++. really neat. The tldr is that you can have the federation run a module that vends ${whatever} in exchange for ecash.
Having a mint be a small closed market for different services that you pay for with that market's ecash is a really interesting model.
For example, you could make a cloud services market where you have a module for object storage, a module for serverless compute, a module for some SaaS service, etc. The modules/backing services could be made by different companies or teams, and then they delegate account management and last-mile billing to the mint (because its just bitcoin in, bitcoin out).
I'm pretty skeptical ecash for mass-adoption end user payments, but I think ecash for a pluggable platforms of related services makes a ton of sense.
my take on why im excited about ecash, but for different reasons.
nostr:note1ncskr9sgmyfyv4zjjcslk82mhv57vd5n2rag86j2pgxezvag4pcqqr6tup
nostr:npub1m6yz8nwf0xl5cafjy0kurxn6hs67eleft8h4pj57n4tn4s8c8lgqd2mzj9 gave me a walkthrough of the fedimint module interface at bitcoin++. really neat. The tldr is that you can have the federation run a module that vends ${whatever} in exchange for ecash.
Having a mint be a small closed market for different services that you pay for with that market's ecash is a really interesting model.
For example, you could make a cloud services market where you have a module for object storage, a module for serverless compute, a module for some SaaS service, etc. The modules/backing services could be made by different companies or teams, and then they delegate account management and last-mile billing to the mint (because its just bitcoin in, bitcoin out).
I'm pretty skeptical ecash for mass-adoption end user payments, but I think ecash for a pluggable platforms of related services makes a ton of sense.
As long as you stick the landing
Anyone have desktop speakers that they REALLY love?
There’s a bunch of folks doing interesting (sometimes truly bizarre) things in script like implementing MUL with double-and-add or merklized lookup tables, trying to implement a stark verifier, etc. so far we’ve found that the 1000 element stack depth limit is something you need to be aware of, but isn’t *usually* an issue. And i think the places it gets bumped into would be trivially fixed if the stack element limit was raised. Anecdotal, but supports the view that 1000 elements is plenty roomy (*especially* if a stack element was able to be up to 4mb)
Got some juniper seasoned smoked sausage. Legit tastes like a pork g&t
I might even say “especially in an LLM world…”
Even in an LLM world, programming is still the longest lever
