How can the gift card be traced to you easily? Buy the gift card with cash from one of these:

Yes but not on purpose. I once sold bitcoin to a craigslist user at 10% over the spot price. They paid me via paypal, and it turns out they used a stolen account, so the payment was reverted a few days later. However, I had already withdrawn the money and bought more bitcoin with it, so my paypal balance simply went negative. That meant I had taken money out of paypal which I now owed them back, which is the same thing as a loan -- except I got it accidentally and had already used the money to buy bitcoin. There was no interest on this "loan" either. After not depositing any money into paypal for a long time, they handed my account to a collections firm. About a year later I finally paid them back, but only after bitcoin's price rise more than covered the principle of the "loan." So I made out like a bandit. But the "loan" was not on purpose -- it was a result of someone trying to steal from me.

Thanks Tony! My reply is here: #212784

Your idea is possible without needing the seller to run a lightning node. Instead of having the seller create the hodl invoice, you can run a lightning node and create a hodl invoice. This doesn't mean the payment will come to you. Before creating your invoice, get a regular lightning invoice from the seller's ordinary lightning wallet, extract its payment hash, and use that payment hash in your lightning invoice -- which is a hodl invoice. Once that is done, the buyer can safely attempt to pay your hodl invoice, knowing that you can't settle it except by forwarding the payment to the seller -- i.e. by paying the seller's invoice. That action will get you the preimage you need in order to settle the buyer's payment, thus completing the circuit.

My hodlcontracts software is designed to automate some parts of this and make it easy.

Regarding htlc bloating, it is true that lightning node operators sometimes get mad when a payment has a really long htlc because such payments can lock up their liquidity for a long time. However, there are pretty good solutions out there for managing that. It is easy to configure your lightning node not to forward long htlcs, and you can even price them differently by setting up a low-fee node that won't forward long htlcs and a high-fee node that will. Each node's htlc duration limits are part of gossip, so wallets can easily detect if they need to create a long htlc and then seek routes that will forward it.

There are also ways to limit htlc bloating by introducing more messages. For example, a custom routing node can easily delay forwarding long htlcs until it gets a message from the seller saying they are ready to receive the payment. Once they get that message, they can forward the payment and expect instant settlement by the seller, thus avoiding imposing a lengthy lockup period on other routing nodes. People who want such a service could then send long htlcs with low bloat by opening a channel with that custom routing node and sending their payment through that channel. In that case, the only htlc slots that get locked up belong to the custom routing node, who explicitly permits this as a service and therefore (probably) charges a high enough routing fee to compensate for the time value their money loses while locked up.

Everything in the last paragraph is easy to do today with wallets that let users choose their channel counterparties, such as blixt wallet, electrum wallet, and zeus. Most popular LN wallets do not let you to manage your own channels, and thus they cannot take advantage of the above-described technique, but perhaps if such services became popular, the popular wallets would add support for it. In the mean time, you could just recommend better wallets for an optimal experience, but still -- even using a basic wallet with no channel management features -- such payments should work just fine, and if routing nodes get mad that their htlc slots get locked up as a result, they can increase their fees for long htlcs using the tools that are already available.

So don't give up on your idea! It is very possible to do today.

If they only want the payment hash, you can get that from the original invoice you paid

Copy the invoice you paid from the "History" section of Wallet of Satoshi and paste it into lightningdecoder.com

The payment hash is one of the fields it displays

A payment hash is typically used by a service provider to look up an invoice in their database and view its status (paid or unpaid), which is why they might want it

But there is another piece of data called a "preimage" or sometimes a "prehash," and in typical lightning parlance, possession of the preimage is what constitutes your proof of payment (it's essentially a receipt)

It doesn't sound like they want that -- they probably just want to look up the status of the invoice you paid, which is what you can use the payment hash for -- but if they do need the preimage, I don't think Wallet of Satoshi shows you that (which is a bit stupid, because it's an important piece of data, but whatever -- I guess they don't think it's important)

No. "Hodl contracts" is the name of a python app I made that uses hodl invoices to emulate an oracle service on the lightning network. Hodl invoices allow a merchant -- Bob -- to programmatically settle or cancel a payment from Alice, but they (Bob) have the private key necessary to do that, so it's fully custodial. Hodl contracts are different. They allow a routing node -- Carol -- to conditionally forward or cancel a payment from Alice to Bob, but the third party does not have the keys to the money (Carol is just a routing node), so she does not have custody of the funds.

Robosats uses hodl invoices for escrow, but they do not use hodl contracts. As a result, robosats is a fully custodial service. When you enter a contract on robosats, you send your collateral to Robosats, not your counterparty, and they use hodl invoices to conditionally settle or cancel your collateral payment depending on whether there is a dispute. (If there is no dispute, they cancel your collateral payment, thus giving you your money back; if there is a dispute, they settle your collateral payment, thus retaining your money until they can decide whether you should get it back or your counterparty should). But since they have all the keys they need to settle the HTLC, they have full custody of the collateral for the duration of the trade. "Whoever holds the keys holds the coins," and in the case of Robosats, Robosats holds the keys. So yeah, Robosats is a fully custodial service, just like coinbase or binance, but anonymous (and made by a fellow who I personally vouch for because I think he is trustworthy).

If by "use regular payments" you mean "use the base layer," I agree. Long duration contracts typically involve large amounts, and for large amounts, the base layer works wonderfully. There are no time limits and there are great tools for making conditional payments, such as 2 of 3 multisig, hashlock contracts, and discreet log contracts. But in sporting events the typical wager is $8-$10, and I don't think the base layer is very good for such amounts anymore. That's why I want to do something like a sports betting site on lightning.

If by "use regular payments" you mean "pay your counterparty directly, with no oracle," you can only do that if you fully trust your counterparty. What if you send them $50 for a game that's coming up on Saturday but they just run off with your money even though their team ends up losing? What if your team wins but your counterparty never sends you the money they owe you? Conditional payments are needed here, but the recipient shouldn't determine the outcome because they can't be trusted. Hodl contracts allow a third party who both counterparties trust to determine the outcome without taking custody of the money (because they are just a routing node).

I hope you see the difference now. Instead of paying your counterparty directly, pay them through a routing node that will forward or cancel the payment based on the outcome of the game. That's what distinguishes hodl contracts from hodl invoices.

Yes

Yes

But the max HTLC limit is pretty easy to solve -- just open up another channel. The max HTLC limit is something like 425 htlcs per channel, which seems like a very high number to me, especially because, if they are all in use, that means your service is very popular, so you can probably easily afford to just open up another channel and get 425 more HTLC slots.

Not on lightning

Lightning DLCs and hodl contracts have the same problem with HTLC max timeouts being pretty short by default

Many routing nodes won't route a payment if it could lock up their capital for more than 7 days, and if wallets can't find routing nodes willing to do it, they just return a failure

DLCs do allow longer terms on the base layer, but then it's quite common for fees to become a significant portion of your bet size

I doubt very many people will make a $10 wager if the fee is typically more than $0.25

Mutiny is awesome and probably the best thing in bitcoin for the past three years, BUT it is not quite 100% self custody. It's more like 96% self custody. When you receive a payment, they open a just-in-time channel to you and push an amount to you that is equivalent to whatever the sender originally sent, minus a fee. In return, your browser immediately gives the preimage to the payment hash of your original invoice, allowing Mutiny to settle the payment from the sender.

By giving them the preimage, however, you're giving them custody of that money, at least until the just-in-time channel confirms. The reason is because the money in the channel contains your payment, and Mutiny can easily take that money back, while still keeping the money the sender meant to go to you. All they need to do is double-spend the utxo that went into the channel and return it to themselves. Which is very easy because unconfirmed payments are cancelable.

As a result, whenever you receive a payment that causes Mutiny to open a channel to you, they have custody of that money. Typically this is only for a brief period of time, i.e. until the channel confirms, but that means (1) it's not 100% self custody and (2) it's not necessarily "for a brief period of time." How long they have custody of your money for is completely up to them. You do not have control over that and there's nothing you can do to stop them from keeping your money indefinitely -- forever, even.

So yeah -- mutiny is awesome, and it's even 96% self custody. But it's not 100% -- not yet -- and I think that's important to point out. Appreciation for these guys and what they are doing is great but their product is only nearly perfect. (I estimate about 96% perfect. Which is awesome! Like, jump-off-the-walls awesome! It's so cool and mesmerizing I am flabbergasted by the implications! But it's not quite perfect. Not yet.)

One thing I've noticed: almost all nostr profiles have a display name, a picture, and a bio, and almost all of them seem to be stored exclusively on relay.damus.io. I've connected to the top 5 relays on nostr.watch, queried for metadata for random accounts, and I only get responses from relay.damus.io. No one else has that data.

I have a theory about why this is too. I think it's because so many people use the amethyst and damus apps, which start off with damus as a default relay, and the first thing they do is create a profile. So that info goes on the damus relay. Later on, they may add other relays or remove damus. But when they created their profile, damus was their main relay. Consequently, damus has almost all profile data, and basically no one else does.

I know one way to help solve this. I could write an app that downloads all metadata posts from damus and rebroadcasts them to other relays. But it feels like there's an underlying problem there that this idea doesn't address. The underlying problem, I think, has to do with the intersection of "wanting to set reasonable defaults for your users" and "not wanting to make everyone reliant on just one relay." Setting people up on the damus relay by default is a good idea, because so many people are using it. But defaulting to damus also means damus has a bunch of data that few other relays have. And right now, at least for profile data, it seems to me there's an imbalance toward the latter.

Please add a #3 strategy where you "go long" by selling to people who want a covered call position

It seems like covered calls involve a taker sending 1 btc (or some other quantity) to a maker, and in return the maker sends them a variable amount of BTC later, where the variable amount is always higher in USD terms than the value of whatever quantity of bitcoin the taker originally sent them. That "guarantees" USD yield for the taker, and a USD expense for the maker, and the maker just hopes his USD expense is offset by a corresponding gain in the price of BTC. Consequently, if I think the value of btc will rise in a way that outpaces the additional value the taker will get, then I want to be a maker rather than a taker.

Does your app let me be a maker instead of a taker? If not, why not?

Rusty got a little confused and thought you can already do covenants in bitcoin by putting signatures in outputs

He soon realized he was mistaken: https://twitter.com/rusty_twit/status/1677822275264069633

But fear not, we can still do key deletion covenants! They have problems that greatly limit their usefulness, but still!

See here for more about them: #197438

Cool! What is your org?

Yeah! You can also use it for p2p loans. Make a 2 of 3 bitpac between a borrower, a lender, and a neutral third party. Have the borrower put some collateral in the bitpac address and have the lender send him some USD. If the lender pays off his loan on time, the borrower or the neutral third party can cosign with the lender to return his collateral to him. If not, the lender or the neutral third party can cosign with the borrower to pay it off using part of the collateral, then send the remainder (if any) back to the borrower.

What's also cool is that the neutral third party doesn't even need to know they are involved unless there is a dispute. You could use Marty Bent for example and only ask him to intervene if your counterparty acts unfairly.

The same principle applies for stuff like futures contracts. One person goes long and is supposed to get some money if bitcoin's price rises by a certain date. The other person goes short so he takes the opposite gamble. If both parties cooperate, they can cosign together to release the funds to the winner. If either one is a sore loser and won't sign to release the funds, the winner can contact the neutral third party and ask them to intervene.

But unlike with DLCs, the neutral third party doesn't need to run a server, or even know they are participating.

Make a bitpac with your friends and then do a tiktok about it

A few reasons

I saw a project on ethereum that lets you vote on how to spend some funds in a group and I wanted to do it too, but with bitcoin, so I made an app for that

I also think it would be really cool if this had existed back when Jack gave some money for nostr development -- it would have been a cool way to distribute responsibility for the funds

I think any charity can use this to demonstrate how they use contributions in a fair way

I think governments can use this to ensure they are accountable for their treasury decisions

I think businesses can use this to distribute responsibility for corporate funds

I think fan clubs can use it for membership dues

Basically I saw a need for a way for people to jointly hold money but be public about how they are using it, and this is one of the many things bitcoin fixes

Thanks! I hope a lot of people enjoy this project. There's are many thing people like doing in groups, maybe using bitcoin can be one of those things