Lending/borrowing BTC is only really useful for explicitly shorting BTC as in margin trading. It is otherwise too risky to borrow BTC, your loan could end up costing way more than a loan denominated in a less volatile asset. For example, imagine borrowing 1 BTC in March 2020 and expecting to pay back the loan by the end of the year... you'd receive $4000 in value at the time of the loan and by the end of the year have to pay back over $50,000 in value. Not a very good deal for the borrower.

Loans collateralized by BTC give borrowers the ability to unlock the value of their BTC without having to sell. Because the loans are over-collateralized, they can have lower interest rates than unsecured credit. It does of course require the borrower to already have assets in the form of BTC, so would not be appropriate for people who have very little in savings. But for people who hold BTC and want to access some of that value without having to sell, and are willing to maintain a sufficient collateral ratio to avoid liquidation, I think it is a good option.

There is a platform called Sovryn that offers both options, borrowing BTC, and borrowing using BTC as collateral: https://alpha.sovryn.app

You can look there and see the terms and interest rates and see what makes sense for your situation.

I wanted to write my own games. Which at age of 7 I actually managed to sell to other kids for decent snack money.

Nice work! Might I suggest a timely SBF portrait? Maybe an American Gothic takeoff with Caroline?

When making grand claims about European providerism, and putting citation numbers, i was expecting some literature to support these claims. But no.

The author seems to base his impressions of Europe on some past experience where he was living in a closed little bubble. Many of my European friends work for promising start ups, incidentally leveraging the field the author seems to know so much about, namely machine learning. Based on my little bubble experience, Europe is leading the way on many technological fronts.

Bringing us back to the need for objective studies to support grand claims~~

Day 265 of snailposting everyday 'til BTC hits $100k.

...and 65 push-ups. (30 - 30 - 5)

__@_'-'

it looks like you're a little confused about the differences between LN address memos and keysend messages.

Sphinx and Juggernaut do not use LN address, they use keysend. Keysend is a type of lightning payment in which the sender creates a payment preimage, uses it to lock up a payment for a recipient, encrypts the whole package (including, optionally, a message), and sends the encrypted blob to the recipient over lightning.

To routing nodes, a keysend payment looks like an ordinary payment, but it's a little weird "under the hood" because of something called reverse flow. In most lightning payments, the recipient acts first: he creates an invoice for the sender, shows it to him, waits for a payment blob to come in on lightning, and accepts the payment by revealing the preimage (aka the proof of payment) that locks up the money.

With reverse flow, the sender acts first, there is no invoice, the sender already knows the preimage to the payment (because he created it), and therefore there is no proof of payment. And these weird "keysend" payments can also include a message. Which is, you know, neat.

Keysend messages are end to end encrypted. As the name suggests, they are encrypted to the recipient node's public key. Only the node with the private key to that public key can read them. (Though the sender also knows what the message says because he created the message. That's why there are 2 "ends" in the term "end-to-end encrypted.")

As for a character limit, the upper bound is 1300 bytes (i.e. 1300 characters), but it's never actually that high. Lightning nodes refuse to forward onion packets that are bigger than 1300 bytes, but a lot of that is "used up" by things other than the keysend message. E.g. every hop in the route adds more bytes to the size of the onion packet because you need to include instructions for that "hop" about who to forward the payment to.

So the "maximum" size limit is variable and never exceeds 1300. The "practical" size limit depends on how long your route to your destination is, but basically the smaller the message, the better. You can't even say something like "just stay under 500 bytes and you'll be good." It's possible for a lightning payment to have so many hops and so much extra payment data stuffed in that there is simply no room left for a keysend message. But the shorter your route, and the less complicated your payment is, the more room you have for a keysend message -- it can fill up however much room is "left over" in your payment.