public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Burak Keceli <burak@buraks.blog>
To: "David A. Harding" <dave@dtrt.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Date: Wed, 7 Jun 2023 16:30:07 +0300 (TRT)	[thread overview]
Message-ID: <345972294.3114897.1686144607871@eu1.myprofessionalmail.com> (raw)
In-Reply-To: <c78b9e621e994f3cf3500e4480b61b0e@dtrt.org>

> A problem with the idea of using one-show signatures as double-spend
> protection is that miner-claimable fidelity bonds don't work as well
> against adversaries that are not just counterparties but also miners
> themselves. 

Hey David,

The fidelity bonds in the Ark context are nothing but the vTXOs themselves, which in simple terms, have two possible closures: (1) a key-path collaborative closure with higher precedence and (2) a script-path closure with lower precedence.

The key-path closure is a 2-of-2 between the rightful owner of the vTXO and the service provider. The script path closure, on the other hand, lets the service provider sweep funds after a relative lock time. The key-path closure has higher precedence over the script-path closure since it can be triggered immediately with a satisfying signature.

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). If Alice (or the service provider) is a miner she won’t be able steal funds regardless, since she won’t be able co-sign from the Bob’s key.

Best,
Burak


  reply	other threads:[~2023-06-07 13:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22  7:54 [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution 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 [this message]
2023-08-06 22:43     ` Antoine Riard
2023-05-25 12:12 Ali Sherief
2023-05-26  7:33 jk_14
2023-05-28  6:02 Ali Sherief
2023-06-07 18:20 David A. Harding
2023-06-11  9:19 moonsettler

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=345972294.3114897.1686144607871@eu1.myprofessionalmail.com \
    --to=burak@buraks.blog \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dave@dtrt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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