The People Want Degenerate Gambling \ stacker news ~bitcoin

pull down to refresh

2109 sats \ 33 comments \ @nerd2ninja 6 Aug bitcoin

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.

view all related items

546 sats \ 6 replies \ @Undisciplined 6 Aug

I feel like he's calling you out, @ek.

481 sats \ 5 replies \ @k00b 7 Aug

At least let him review my PR first.

517 sats \ 4 replies \ @ek 7 Aug

me reading up on HTLCs

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.

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:

Alice generates a temporary private key dA1 and its corresponding public key PA1 and sends the public key to Bob.

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.

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.

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.

300 sats \ 0 replies \ @k00b 7 Aug

BOLT 2's guide on setting cltv deltas is also helpful.

1400 sats \ 1 reply \ @NostrDice 7 Aug

Have you looked at what we built with NostrDice? :) See here: #631870

100 sats \ 0 replies \ @nerd2ninja OP 10 Aug

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.

131 sats \ 10 replies \ @supertestnet 7 Aug

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

156 sats \ 9 replies \ @nerd2ninja OP 9 Aug

The random person getting a notification that there's a bet dispute to resolve deciding they're too busy for all that

177 sats \ 8 replies \ @supertestnet 9 Aug

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."

0 sats \ 7 replies \ @nerd2ninja OP 9 Aug

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.

145 sats \ 6 replies \ @supertestnet 9 Aug

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.

0 sats \ 5 replies \ @nerd2ninja OP 9 Aug

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

0 sats \ 4 replies \ @supertestnet 9 Aug

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.

0 sats \ 3 replies \ @nerd2ninja OP 9 Aug

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?

view replies

311 sats \ 0 replies \ @Satosora 6 Aug

I have never really agreed with the gambling bitcoin sites. Anyway, does anyone remember primedice? I saw people throw away so many bitcoin....

310 sats \ 0 replies \ @grayruby 6 Aug

Give the people what they want!

186 sats \ 0 replies \ @zapsammy 7 Aug

proceeds could go to OpenSats 🤣

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.

302 sats \ 0 replies \ @037aef6755 7 Aug

Let's be realistic, all gambling games are not done for someone to win, but for more people to lose!

0 sats \ 0 replies \ @Satoshi__Nakamoto 7 Aug

It would be better if people have to do what they like most wether it gambling or any things

0 sats \ 1 reply \ @iam_jerry 7 Aug

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.

100 sats \ 0 replies \ @nerd2ninja OP 7 Aug

We are the damn market. Social pressure is a market pressure.

0 sats \ 0 replies \ @Octopus 7 Aug outlawed

stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.

0 sats \ 3 replies \ @BitcoinAbhi 7 Aug

deleted by author

0 sats \ 2 replies \ @fiatbad 7 Aug

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.

0 sats \ 0 replies \ @iam_jerry 8 Aug

I agree. "The shortcut to success in this fiat world is to be as close as possible to theoney printer." You're damn right.

0 sats \ 0 replies \ @BitcoinAbhi 7 Aug

deleted by author