From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 513F3907 for ; Sun, 28 Jul 2019 14:17:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8CE5D604 for ; Sun, 28 Jul 2019 14:17:37 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id y4so59058796wrm.2 for ; Sun, 28 Jul 2019 07:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DuEAgEXz/XirREZPX3ktRxtrdg8h0tcDYfMKVI1zE8g=; b=ZU4h5/4viGQKaVaBUT9TBz3be9RNv4zaJIEOgiOqR0vYWsAIqUjedV3R7vpnvLTi5I XOAe03UkM3LmbUQ6ZaRO9nKgvn+jazm3YSYCgCogCgE5h5gUO7rj0IPJEznP87NB+qld +xvkr9bTs2gfQOvrXiGiw1ECUhG6t4xLLn5U0poXU8uZVNaNH/gKNDtNHMeu4lGKXfO1 BFvQHYTDhgwOKwtBd3AZxL45Dlr8WO4u/Ke7EOTWBO0OTTluVDJ1gAk+3cT08uvHogI2 N81YhTd7BtptAHgUhRq5yW77M0lMnV5Z+hvYIIXVP8rSLiR52OCQ5TUeSAQVZmTFbaCB X91Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DuEAgEXz/XirREZPX3ktRxtrdg8h0tcDYfMKVI1zE8g=; b=GUud+2hbf57SGJkmiFEyHgRSteHjwJAKuKs/q/tRE/A+qp4Y48ZLoY7cxfPhsTzSfk sDq2FNKlEusKpnxrxrnJCvWU0x1ILc7gWHmSsIbn0+IpORXyhftYp7+cNa6Kfn7PlMgn XVNKqXHcOctSinMB2LO/BLc6oJT4B6a9fylcItvj0OaMB+sTpNhGLqsU4WdqGvMGSJ+8 xnKLaH8Lr/ugKLk+ktYqRYwWvW8XV9cNT4r3+lDPOZNq5013LR5p9pADEfaTzdhFHNyG GqJOuC6xR1h3TEPFbafCf9Qk2A6klHVZ1BASQk9yxh1ySC+QiL1SPfmP+iv+4FGws7c0 KJzg== X-Gm-Message-State: APjAAAWWrzfQlKIO5I4uyUMbagkB28oXMcpzBaBmRCfjhSuI3Qygmiau kJAJ7UzceeNDPX6mhGq5zJc= X-Google-Smtp-Source: APXvYqy4nssICjtyt0fschqXw1qJUmjy/5uxa/Odm3DVNLWvy7w7WCaDDvhuxY4mzr2GLefuwib1DQ== X-Received: by 2002:a5d:6408:: with SMTP id z8mr98168250wru.246.1564323456162; Sun, 28 Jul 2019 07:17:36 -0700 (PDT) Received: from p200300dd671264299d437b6c54af3524.dip0.t-ipconnect.de (p200300DD671264299D437B6C54AF3524.dip0.t-ipconnect.de. [2003:dd:6712:6429:9d43:7b6c:54af:3524]) by smtp.gmail.com with ESMTPSA id g12sm85892537wrv.9.2019.07.28.07.17.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jul 2019 07:17:35 -0700 (PDT) From: Tamas Blummer Message-Id: <8E474FF2-B6D0-4AFC-AD6F-9A8071F1527C@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_32137B37-79A8-44AE-B23E-F75B6463AAC0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 28 Jul 2019 16:17:35 +0200 In-Reply-To: <20190727193417.cxf544dbempencql@ganymede> To: "David A. Harding" , Bitcoin Protocol Discussion References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net> <20190727193417.cxf544dbempencql@ganymede> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 29 Jul 2019 02:53:15 +0000 Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2019 14:17:38 -0000 --Apple-Mail=_32137B37-79A8-44AE-B23E-F75B6463AAC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi David, Aquiring coin age is hard not only for an attacker but for any user that happened to move his funds lately. Even if coin age is available, proofs of using it to fund a particular = operation are not sybill resistant. Only a centralized service would know for sure = that proof is only used once and such centralization would defeat the = purpose. In contrast time locking such that it is uniquely linked with the = operation is always possible as funds could also be rented to lock in a = decentralized manner. Regards, Tamas Blummer > On Jul 27, 2019, at 21:34, David A. Harding via bitcoin-dev = wrote: >=20 > On Thu, Jul 25, 2019 at 12:47:54PM +0100, Chris Belcher via = bitcoin-dev wrote: >> A way to create a fidelity bond is to burn an amount of bitcoins by >> sending to a OP_RETURN output. Another kind is time-locked addresses >> created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being >> sacrificed is time rather than money, but the two are related because = of >> the time-value-of-money. >=20 > Timelocking bitcoins, especially for long periods, carries some = special > risks in Bitcoin: >=20 > 1. Inability to sell fork coins, also creating an inability to = influence > the price signals that help determine the outcome of chainsplits. >=20 > 2. Possible inability to transition to new security mechanisms if > a major weakness is discovered in ECC or a hash function. >=20 > An alternative to timelocks might be coin age---the value of a UTXO > multiplied by the time since that UTXO was confirmed. Coin age may be > even harder for an attacker to acquire given that it is a measure of > past patience rather than future sacrifice. It also doesn't require > using any particular script and so is flexible no matter what policy = the > coin owner wants to use (especially if proof-of-funds signatures are > generated using something like BIP322). >=20 > Any full node (archival or pruned) can verify coin age using the UTXO > set.[1] Unlike script-based timelock (CLTV or CSV), there is no = current > SPV-level secure way to prove to lite clients that an output is still > unspent, however such verification may be possible within each lite > client's own security model related to transaction withholding = attacks: >=20 > - Electrum-style clients can poll their server to see if a particular > UTXO is unspent. >=20 > - BIP158 users who have saved their past filters to disk can use them = to > determine which blocks subsequent to the one including the UTXO may > contain a spend from it. However, since a UTXO can be spent in the > same block, they'd always need to download the block containing the > UTXO (alternatively, the script could contain a 1-block CSV delay > ensuring any spend occurred in a later block). If BIP158 filters > become committed at some point, this mechanism is upgraded to = SPV-level > security. >=20 >> Note that a long-term holder (or hodler) of bitcoins can buy = time-locked >> fidelity bonds essentially for free, assuming they never intended to >> transact with their coins much anyway. >=20 > This is the thing I most like about the proposal. I suspect most > honest makers are likely to have only a small portion of their funds > under JoinMarket control, with the rest sitting idle in a cold wallet. > Giving makers a way to communicate that they fit that user template > would indeed seem to provide significant sybil resistance. >=20 > -Dave >=20 > [1] See, bitcoin-cli help gettxout > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_32137B37-79A8-44AE-B23E-F75B6463AAC0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl09rn8ACgkQ9nKRxRdx ORxa1Af9Hn6Goxv8OoQjFRy5xVq1+fE4lBiGtdQSTOKOD4oN/xrwU41DQDoyuZ4n 53N1NHmfMRrXq8jXWb1penqy9IK2JataqfgZIVqz+aDi1ZWrSJcpaszgnLOU3DBu nSPsTHk7dpSKS6xbm7Eag491N5q5RU58pxtSaHUWWEQPKA1JN9Ql3RogZu/jGmw2 yLXsVc/jSUA9b95p7bJtGcVb+lZLREptJHRZRjFF4sEzJcfv8GGRRQenPbUtDIc3 f4LdR710bJXc5bRIVhg9PaAzM28Hud4IEl5HXANVTTqxY0Z6AoXiagveB/jMlfKH WoB9+t6brx41Xl8QHPil9YCHuFLg+A== =e/Vo -----END PGP SIGNATURE----- --Apple-Mail=_32137B37-79A8-44AE-B23E-F75B6463AAC0--