pull down to refresh
113 sats \ 1 reply \ @BlueSlime 13 Oct \ on: Let It Be or Hard Fork? security
Don't store your funds in taproot addresses and you will be fine. Use Pay-to-Pubkey-Hash, (P2PKH) or Segwit (P2W-PKH). The hash will protect you from zero-day quantum attacks.
The "intelligence-detecting" is rather cheeky, considering one spook at Langley just has to walk down the hall and ask the other spook in charge what their ayatollah has planned for the weekend.
This is a fantastic article. Well-researched, neatly formatted, full of references, great summaries and an unbiased view of the current Bitcoin layer-2 space.
My compliments to the chef. 😙🤌
There are more sinister ways to attack digital signatures than this.
FYI if your device uses a nondeterministic nonce when signing, then it is impossible to verify whether your signatures have been tampered with.
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