pull down to refresh
0 sats \ 7 replies \ @nerd2ninja OP 9 Aug \ parent \ on: The People Want Degenerate Gambling bitcoin
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.
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?
reply
if you find something dishonest in what I said, please point it out
reply
In my view, the ecrow provider is the centralized point. There isn't much of a functional difference in if they have a website or not.
Now, to be fair to you, you said you didn't need a centralized backend as in infrastructure so yeah I mean you could do this in person right.
I think there's a lot of not seeing the difference between federated things for example and decentralized things in our usual sphere of influence and I think that is caused by marketing teams often which has gotten to the point of confusing all of the people within our general sphere who are influenced by those marketing teams. So the way you deconstruct all of that is to reject it. So I'm sorry if this feels like I'm being silly and making unnecessary commentary, but I do feel like its necessary.
reply
I agree with almost all of what you say here and I hope I also live up to my duty (as I perceive it) of calling out the error of treating federated solutions as decentralized
I do, however, think "not having a website" makes a big functional difference. If people pick escrows through an informal mechanism (e.g. "well we both know Bob, Bob is awesome. He wouldn't cheat either of us. In fact, let's just ask him if he'll do this for us") then no one except the interested parties ever has to know Bob did anything.
reply