From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: AdamISZ <AdamISZ@protonmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Date: Tue, 10 May 2022 16:54:31 +0000 [thread overview]
Message-ID: <Xjq4gzy3me86tG6sYumDq16JE8EpRSnC90Ao-02Fyz3i55vRlLY7QKbW9TdaSJg8hiclxpBqhW93CtNgeCzVmbN3CDaW35P3BZwYp1o54H0=@protonmail.com> (raw)
In-Reply-To: <dI-CkifjUyQssT-JzKmv09W6NggL89orF78qz1AOFlBL7Kmxo6z5BVBEr6aZha_nbnBQHFcN1hqC5EZM7lB0U0jiBtE3ZWCiIR_dGBJMsDA=@protonmail.com>
Good morning waxwing,
> ------- Original Message -------
> On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Hello ZmnSCPxj,
> > This is an intended feature. I'm thinking that the same fidelity bond
> > can be used to running a JoinMarket maker as well as a Teleport
> > (Coinswap) maker.
> > I don't believe it's abusable. It would be a problem if the same
> > fidelity bond is used by two makers in the same application, but
> > JoinMarket takers are already coded to check for this, and Teleport
> > takers will soon as well. Using the same bond across different
> > applications is fine.
> > Best,
> > CB
>
> Hi Chris, Zmn, list,
> I've noodled about this a few times in the past (especially when trying to figure out an LSAG style ring sig based FB for privacy, but that does not seem workable), and I can't decide the right perspective on it.
>
> A user sacrifices X amount of time-value-of-money (henceforth TVOM) by committing in Joinmarket with FB1. He then uses the same FB1 in Teleport, let's say. If he gets benefit Y from using FB1 in Joinmarket, and benefit Z in Teleport, then presumably he'll only do it if (probabilistically) he thinks Y+Z > X.
>
> But as an assessor of FB1 in Joinmarket, I don't know if it's also being used for Teleport, and more importantly, if it's being used somewhere else I'm not even aware of. Now I'm not an economist I admit, so I might not be intuit-ing this situation right, but it fees to me like the right answer is "It's fine for a closed system, but not an open one." (i.e. if the set of possible usages is not something that all participants have fixed in advance, then there is an effective Sybilling problem, like I'm, as an assessor, thinking that sacrificed value 100 is there, whereas actually it's only 15, or whatever.)
>
> As I mentioned in https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/993#issuecomment-1110784059 , I did wonder about domain separation tags because of this, and as I vaguely alluded to there, I'm really not sure about it.
>
> If it was me I'd want to include domain separation via part of the signed message, since I don't see how it hurts? For scenarios where reuse is fine, reuse can still happen.
Ah, yes, now I remember.
I discussed this with Tamas as well in the past and that is why we concluded that in defiads, each UTXO can host at most one advertisement at any one time.
In the case of defiads there would be a sequence counter where a higher-sequenced advertisement would replace lower-sequenced advertisement, so you could update, but at any one time, for a defiads node, only one advertisement per UTXO could be used.
This assumed that there would be a defiads network with good gossip propagation so our thinking at the time was that a higher-sequenced advertisement would quickly replace lower-sequenced ones on the network.
But it is simpler if such replacement would not be needed, and you could then commit to the advertisement directly on the UTXO via a tweak.
Each advertisement would also have a specific application ID that it applied to, and applications on top of defiads would ask the local defiads node to give it the ads that match a specific application ID, so a UTXO could only be used for one application at a time.
This would be equivalent to domain separation tags that waxwing mentions.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2022-05-10 16:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-01 8:57 [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds Chris Belcher
2022-05-01 9:43 ` ZmnSCPxj
2022-05-01 10:01 ` Chris Belcher
2022-05-01 11:41 ` ZmnSCPxj
2022-05-02 9:23 ` Chris Belcher
2022-05-03 5:26 ` ZmnSCPxj
2022-05-03 18:03 ` Chris Belcher
2022-05-03 18:26 ` Eric Voskuil
2022-05-04 2:37 ` ZmnSCPxj
2022-05-04 4:04 ` eric
2022-05-04 4:19 ` ZmnSCPxj
[not found] ` <01c401d86a5c$956ddbd0$c0499370$@voskuil.org>
2022-05-18 3:06 ` eric
2022-05-18 6:29 ` ZmnSCPxj
2022-05-21 21:36 ` AdamISZ
2022-05-10 12:31 ` AdamISZ
2022-05-10 16:54 ` ZmnSCPxj [this message]
2022-05-10 19:03 ` AdamISZ
2022-05-10 19:28 ` AdamISZ
2022-05-13 10:02 ` Chris Belcher
2022-05-13 12:44 ` ZmnSCPxj
2022-05-15 9:13 ` Chris Belcher
2022-05-16 0:00 ` ZmnSCPxj
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='Xjq4gzy3me86tG6sYumDq16JE8EpRSnC90Ao-02Fyz3i55vRlLY7QKbW9TdaSJg8hiclxpBqhW93CtNgeCzVmbN3CDaW35P3BZwYp1o54H0=@protonmail.com' \
--to=zmnscpxj@protonmail.com \
--cc=AdamISZ@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.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