0 sats \ 0 replies \ @BlueSlime 10 Jul \ on: Wasabi Wallet Security Incident bitcoin
Very in depth writeup, was a great read.
Nostr is a naive protocol. The relays are meant to be dumb and agnostic.
Anyone can extend the protocol to build literally whatever they want. You can use other relays, or run your own.
The core protocol fits entirely inside a single proposal (NIP-1). If your custom protocol is NIP-1 compatible, then your protocol will work on any relay.
If users want decentralization, they will build and support clients that offer decentralization. Anyone can build a p2p protocol over dumb nostr relays.
Nostr shade is the new javascript shade. Haters are gonna hate, builders are gonna build.
Yes it is a very beautiful and historic place. It has also been razed and burned to the ground, and rebuilt several times, so there's a lot going on underground as well.
The latest improvements have halved the number of rounds required for verification, reducing the worst-case scenario to approximately 19 rounds (38 transactions) and consuming around 400K weight units (WU) in total.
The most important part of the article.
Some of the docs are still a bit out of date, still working on updating everything.
The playground still needs some work and polish. We plan on ditching the low-tech passing of URLs around for negotiation, and using nostr instead.
Let me know if you have any questions about the playground.
We don't have frost implemented yet, but when it's ready we will be using it to federate the escrow server's side of the 2-of-2 address. For the user side of things, all multi-sig inputs are handled by the smart contract (we have a whole smart contract execution layer).
You can specify any pubkey you wish to be Carol, and Carol can specify any funds she wants to get paid.
Carol could also act as a coordinator between Alice and Bob, and just use BitEscrow as the escrow service. Our protocol is designed for third-parties to help handle contract negotiation and mediate.
IMO The best mental model for conveying proof of work to a layman is to explain it as a lottery game, where you have to guess a magic number to win.
The magic number is very large, completely random, and unknowable beforehand. The only viable strategy is to guess randomly until you get it.
That is an easy enough game for anyone understand, though it sounds like the most boring game on earth.
However, one upside is that you can guess as much as you want, as quickly as you can handle. So it makes better sense to play this game using a computer, where essentially the most computation wins.
It is also the simplest and fastest provably fair lottery system that you can play amongst computers. There are no ways to cheat and no central authority conducting the lottery. It's just a game of math and computation that a network of computers can play.
So while this lottery may be the most boring game on earth to humans, it can provide great utility for computer networks, and it happens to scale incredibly well.
The greatest example of course (in hindsight) is to run a peer-to-peer decentralized banking system, where computers can compete in the lottery to make updates to the central ledger, in a way that's provably fair across the network.
But another good example is spam prevention, where the lottery is kept fairly easy to play for a single round, but scales very poorly for multiple rounds (i.e a spam attack). Proof-of-work was invented originally for this use-case.
I hope this helps.
With PTLCs you should be able to split payments like that. You could lock an invoice to the sum of a set of invoice secrets, for example (since points can be added).
I don't see anything wrong with this. Alice is locking funds to Carol's secret, which is no different than routing an HTLC.
In practice, wrapped invoices will probably scale very poorly. This is because the lightning node for Alice will only consider routing to Bob, and the lightning node for Bob will only consider routing to Carol. The route will not be optimized at all.
The solution for this of course is to to build a Bolt 11 invoice with all your Bob nodes specified in the route. Then the path-finding logic for Alice's node will try to build an optimal route.
For some reason, LNURL doesn't implement the routes attribute from the LUD-06, even though it is named in the spec. It would be nice if it did, because then you could specify members for a multi-party payment.
However, this still doesn't solve the problem, because adding Bob to the route doesn't mean that Bob will know to intercept that invoice, and charge a certain fee.
So then what you need is an HTLC interceptor, that is looking for a specific payment hash, so that Bob's node can charge the correct fee. But I'm not sure to what extent you can get away with this, as you may have to mess with your node's pathfinding API, and every implementation is different.
So in addition to the above, you may also need to analyze the graph and build the route yourself, then have your node setup the HTLC, then pay the invoice.
Much of the above is pure speculation and I may be completely wrong.
I have also thought about this problem quite a bit myself 😅
wow this is really cool
this is a great idea and you picked a great name, can't wait to check it out
Congrats on the first tx!
Is there a method for SPV of taproot assets? Or does it require an indexer?
Thank you for the shout out. :-)
The tool is still very experimental. There's a lot of UX that needs to be improved, better tutorials and guidance on creating a contract / roles, a better interface for the VM itself and what it is doing, bug fixes and documentation, etc. There is still a long list of things to do 😁
So far it has been very useful for testing various contracts and debugging the VM.
If y'all have any questions please let me know.
This looks sexy AF.
The best thing nostr has going is the decentralized identities and cryptographic signing.
If you add the hardest e2e private messaging standard on top, then nostr will be a killer app.
I don't believe anyone really wants to be spied on. Even normies are getting salty from the endless tentacle-rape of their electronics by the orwellian surveillance octopus.
If I could ditch signal for a private messaging nostr app, I would do it in a heartbeat and compel all my normie friends to join. And I don't think it would take much persuading to get them onboard.
One thing that is missing though, is a way to manage nostr identities in a mobile wallet. With a much better interface than NIP-7 that supports protocols like this NIP directly.
I would create the longest transaction chain ever, with each transaction time-locked to the next block, and spending 1 BTC in fees. Then publish the 100mb transaction blob and delete the private key.
This should guarantee miners a 1 BTC subsidy for the next 20 years.
Or burn it all in an op return.
Runes are basically a colored coins protocol designed for issuing tokenized assets. They are designed to replace BRC-20 with something more sensible. They are UTXO based, and rely on the OP_RETURN to store the token data (called a runestone). They do not use the ordinal system for anything, but a rune can be tied to an inscription.