BISQ has an escrow and dispute resolution system: https://docs.bisq.network/trading-rules
Some people might enjoy a degenerate gambling website where you bet on the outcome of events (sports betting, who wins an election etc) that uses this system for its custody.
The person who builds this will likely make a bunch of money from collecting fees, but please for the love of humanity, be just a little humanitarian in this scenario where we're talking about enabling degenerate gambling lel, and don't fucking lie about what the system is.
Don't call this decentralized. Someone has to push the button to tell the computer what the outcome was. Also you don't need overly complicated bullshit to make this work, often that over engineering merely serves the purpose of hiding what's actually happening.
Just be an honest actor and make a bunch of money.
I feel like he's calling you out, @ek.
reply
481 sats \ 5 replies \ @k00b 7 Aug
At least let him review my PR first.
reply
reply
456 sats \ 3 replies \ @k00b 7 Aug
I recommend Elle Mouton's HTLC Overview and HTLC Deep dive too if you feel like anything was ambiguous.
reply
146 sats \ 1 reply \ @ek 7 Aug
Thanks, that was very helpful!
I started reading it from the beginning and got stuck on a question about revocation yesterday:
In Part 2, the revocation key system was described as follows:
  1. Alice generates a temporary private key dA1 and its corresponding public key PA1 and sends the public key to Bob.
  2. Then Alice creates a commitment transaction where the to_local_output output has a spending path that is immediately spendable by Bob if he has the private key dA1.
  3. If Alice and Bob agree to update their channel state, then the private keys for the previous state will be swapped (ie: Alice will send Bob dA1).
For some reason, I assumed that Alice would sign her commitment transaction with dA1 if she ever wants to broadcast it. But when she gives dA1 to Bob later to revoke this commitment transaction, I thought Bob could simply create, sign and broadcast her commitment transaction himself and then penalize her for it, taking all the funds of the channel. I think I had essentially the same question as someone had here.
The answer is that since all commitment transactions spend the same multisig output of the funding transaction, the commitment transactions need a signature from these private keys. And Bob does never receive Alice's private key for that signature. He can create the commitment transaction but not Alice's signature.
It's funny how stuff becomes obvious after you struggled with it for a few hours.
reply
111 sats \ 0 replies \ @k00b 7 Aug
I'm fond of reading something for a cursory understanding without taxing myself, letting it background, then repeating periodically until it's pretty much intuitive.
Trying to learn something all at once is like storing all your data in memory. I just write parts of it to disk over a day/couple of days, then try again with all the "indices" my brain made.
reply
1400 sats \ 1 reply \ @NostrDice 7 Aug
Have you looked at what we built with NostrDice? :) See here: #631870
reply
Looks like a decent system. I think the idea of leveraging the unpredictability of a hashing algorithm to be what determines the dice roll is probably the best way to do randomness between two or more participants who have a vested interest in the outcome of the number. That was my real implementation take away.
reply
There is a way to do this without a centralized backend
My celebrity escrow project (live now!) lets users gamble using just a single html file and some bitcoin, and it's perfectly safe to self host that one file
The counterparties have to agree on who to use as the backup key in case there is a dispute, but that person only learns there was a bet if there happens to be a dispute -- and doesn't need to download or host any software to resolve it and collect their fee
reply
The random person getting a notification that there's a bet dispute to resolve deciding they're too busy for all that
reply
Three mitigations:
First, the two players have to agree on what fee the escrow should get in case of a dispute. Make it worth his while or don't sign the contract.
Second, the two players also have to agree on who to use as escrow. If you pick an escrow and choose someone who you aren't sure (1) they will respond (2) honestly...well, then that's probably your fault.
Third, since escrows earn money, they are incentivized to advertise themselves and their rates. They can even charge up front: "if you want to include me in a contract, first pay me 200 sats here <insert-url>, then include a proof of payment in your contract, and offer a 10% reward for settling it honestly. If you have a dispute I will first check if you paid me in advance, then I will check if you paid me 10% in-contract. If both things check out I will pick a winner within 24 hours of receiving your contract."
reply
And so these professional escrow providers might have a centralized backend (their website) and for the sake of customer retention also have a list of bets you can participate in andddd we're back to a website with better custody than any other website, but still centralized lol.
This is the "NOSTR is not decentralized" rule. The ability to hop to as many websites as you want does not make it decentralized. So that's why I'm saying lets just be honest about what the trust assumptions are.
reply
these professional escrow providers might have a centralized backend
And they might not. If someone decides "hey I will run a website!" that does not make a protocol centralized. That website might get taken down, and the escrow might get arrested, but the protocol is still fine and works perfectly well without that particular escrow or their website. Though I do need to implement a backout clause so that if your escrow disappears and you can't come to an agreement, both parties just get their deposits back.
The ability to hop to as many websites as you want does not make it decentralized.
You don't need any websites. If your point is "things can't be decentralized if they have nostr as a dependency," then I agree. And I suppose that means I was wrong to say celebrity escrow lets you do this without a centralized backend, since it requires nostr, which is the same thing as saying "it requires a centralized backend." But in theory it doesn't require nostr -- that's just how I implemented it, because it's easy. The only requirement (theoretically) is a way to communicate with whatever escrow both parties agree on, and that does not require anything centralized.
reply
While we're here, what are we going to do about the potential for out of band payments? Sore loser decides if they bribe the escrow provider they can still make out with the money kind of situation
reply
I think this is covered by my second mitigation:
Second, the two players also have to agree on who to use as escrow. If you pick an escrow and choose someone who you aren't sure (1) they will respond (2) honestly...well, then that's probably your fault.
reply
So trust. Reputation. I'm only asking for honesty. This whole post I was just asking for honesty. Can we be honest about what we're talking about building now?
I have never really agreed with the gambling bitcoin sites. Anyway, does anyone remember primedice? I saw people throw away so many bitcoin....
reply
Give the people what they want!
reply
proceeds could go to OpenSats 🤣
reply
100 sats \ 0 replies \ @kruw 7 Aug
Discreet log contracts are the best way to bet on the outcome of an event since the oracle isn't even aware of the existence of the wager placed by participants.
reply
Let's be realistic, all gambling games are not done for someone to win, but for more people to lose!
reply
It would be better if people have to do what they like most wether it gambling or any things
reply
The market doesn't care about your feelings and/or moral standing. It is what the people want. There will always be those who will be willing to cheat their way out of the system. It all depends on the incentives. Only foolish people will not do their dilligence to verify every bitcoin systems they interact with. And that is why many people will continue to fall victims of bitcoin fraudsters. This is human action in play; you can't do anything to help the addicts. The only way to flush out the fraud is to have majority of bitcoiners active and alert, verifying everything.
reply
We are the damn market. Social pressure is a market pressure.
reply
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.
deleted by author
reply
I'm certain that every person in the Cantillionaire class is laughing at your comment.
The shortcut to success is to be as close as possible to the money printer.
reply
I agree. "The shortcut to success in this fiat world is to be as close as possible to theoney printer." You're damn right.
reply
deleted by author
reply