From: "David A. Harding" <dave@dtrt•org>
To: Burak Keceli <burak@buraks•blog>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Date: Wed, 07 Jun 2023 08:20:33 -1000 [thread overview]
Message-ID: <99b61e0f4a2d488674ebdd1ef48eb347@dtrt.org> (raw)
On 2023-06-07 03:30, Burak Keceli wrote:
> If the service provider double-spends a transaction that enforces a
> one-time signature where Bob is the vendor, Bob can forge the service
> provider’s signature from the 2-of-2 and can immediately claim his
> previously-spent vTXO(s).
Hi Burak,
I'm confused. Bob owns some bitcoins that are timelocked against
immediate withdrawal, but where he can spend immediately with the
cooperation of service provider Sally. Bob transfers some bitcoins to
Sally contingent on her spending an equal amount of bitcoins (minus a
fee) to Carol. You already have a mechanism to enforce this contingency
(tx outpoints), so if Carol doesn't receive the bitcoins from Sally,
then Sally also doesn't receive the bitcoins from Bob. In other words,
you already have atomicity for a single transfer.
Are you describing the effect over multiple transfers? For example, Bob
previously transferred bitcoins to Sally and she paid users X, Y, and Z
in transactions that are now confirmed onchain, although she hasn't yet
swept Bob's funds. Now when Sally double spends the payment to Carol,
Bob can not only reclaim the funds he gave Sally to pay to Carol (which
was guaranteed by the atomicity), he can also reclaim the unswept funds
he gave Sally to pay X, Y, and Z.
If so, I don't think that works. In a private protocol, Carol can't be
sure that Bob and Sally are separate individuals. If they're the same
entity, then any forfeit that Sally needs to pay Bob is just an internal
transfer, not a penalty.
I'd appreciate any clarification you can offer. Thanks!,
-Dave
next reply other threads:[~2023-06-07 18:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-07 18:20 David A. Harding [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-06-11 9:19 moonsettler
2023-05-28 6:02 Ali Sherief
2023-05-26 7:33 jk_14
2023-05-25 12:12 Ali Sherief
2023-05-22 7:54 Burak Keceli
2023-05-22 13:03 ` ZmnSCPxj
2023-05-23 4:31 ` Burak Keceli
2023-05-23 22:06 ` G. Andrew Stone
2023-05-24 0:40 ` ZmnSCPxj
2023-05-24 0:45 ` ZmnSCPxj
2023-05-24 7:53 ` Burak Keceli
2023-05-24 6:28 ` Burak Keceli
2023-05-24 20:20 ` adiabat
2023-05-24 23:02 ` David A. Harding
2023-05-26 11:56 ` Burak Keceli
2023-05-27 20:36 ` David A. Harding
2023-06-07 13:30 ` Burak Keceli
2023-08-06 22:43 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99b61e0f4a2d488674ebdd1ef48eb347@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=burak@buraks$(echo .)blog \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox