pull down to refresh
10 sats \ 14 replies \ @justin_shocknet 26 Mar \ parent \ on: Hedgehog: A protocol for asynchronous layer two bitcoin payments bitcoin
Then I think it'd be responsible to correct this description, lest we perpetuate a mis-understanding about how things work that'll inevitably lead people to scams
I don't immediately agree with you, I have to let your reasoning marinate with me for a bit
But I will remove the word asynchronously from the github and the youtube video just in case you're right
reply
You are like the world champion in dealing with people who I'm not entirely sure are operating in good faith. Very commendable.
reply
Got some actionable feedback for me or is this just tone policing from something else?
reply
I suspect that if you were the type who could take actionable feedback, none would be required.
reply
I got some for you whenever you want it
reply
reply
"asynchronous" is a term used in computer science and programming languages for ages. Asynchronous requests can time out, asynchronous payments can fail after some time, so not sure what the fuss is about. Yes, it's not final settlement until it's settled - but when did we put that in the definition of asynchronous?
reply
It's about whether the asynchronousity is novel
Async payments are a popular want on lightning... If you believe this is async then lightning is too
reply
Yes I believe this is async payment based on this definition (used in Lightning context): https://bitcoinops.org/en/topics/async-payments/ .
It's not fully trustless though.
reply
Which party is trusted? The sender, the recipient, or someone else?
reply
Yeah, that's a good question. I don't know how to answer that well.
If we are using "trustless" as "NOT trusting any third party outside of Alice and Bob", then I guess it's trustless?
But I think the highlight is that Alice can scam Bob in couple ways and Bob may miss on receiving some sats he would otherwise get if we didn't have the "pull back after 2 weeks" clause. This is comparable situation to other schemes, but onchain finality is better experience.
reply
I think the highlight is that Alice can scam Bob in couple ways
How?
reply
On further thought I think my comment was not useful, so feel free to disregard.
What I meant is that the usual social tricks that apply to other solutions apply here too. As soon as you have a setup where money can be "clawed back" later, that opens multiple scam opportunities.
- Alice pays bob in person in some physical corner store, Bob has static address displayed. Alice pays, shows nice checkmark that she paid, Bob believes her and gives the produce in return. Bob doesn't claim the sats for 2 weeks because he's not technical. Alice reverts the payment. Bob notices a week after that and feels scammed.
- Alice can create scam scheme where she uses a visual proof of payment to gain social engineering leverage over Bob. Most of current "fake microsoft phone support center for seniors" scams are based on this. They make you believe that they accidentally send you extra money and ask you to return it. But you never actually received the money in the first place.