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 2B43DC2A for ; Sun, 28 Jul 2019 18:29:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6C4155E4 for ; Sun, 28 Jul 2019 18:29:36 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id p13so59380488wru.10 for ; Sun, 28 Jul 2019 11:29:36 -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=MUImeC5Tcw+yBl3pP0UsrE8JFTojGU3E/GO2uKtWTus=; b=ELifoFg1harWaRA+MuA+TvPbzzQ84nsde+IxWVGStyry8Crlr/2rqAjDf2ClBasq1g 7St8FBFjMLdjXuMA4V+UPnownsSJGt4yoSVs2GpRl5SO2wKA1m30pdNJmmYc6GVO2MMN VvEzshXH+Op4DICpXSNgL4QIlvTv64gmgo/TNopHi3ldtI1AozwZwkmLhQYPevzt190f LqMUlgZkbbr6Zndcye3ELKTkC2ZHuAqkkMrpuOlmLhDCTow0bKiMd3LXJgCTpNaGnWbZ fQtnsVDeSxPJsiGCm7kRfgvQij20G9dNkxGNW7o4mV5/C7f1cMj5T+FTLE050Yk8OTrz Tvvg== 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=MUImeC5Tcw+yBl3pP0UsrE8JFTojGU3E/GO2uKtWTus=; b=ZJ+BT/dpJ+gEuYw1+sSmQQ97W1CzHB7d2GkUDCKF6Bj89hKSoXF2qDA4OvsBWPDuB0 lhN27GMskbdNpeIOYJkdjZK8UTiogH3896s9fAIC2LnKEHOLMaUHsK/ljfgCi6d3sJxG i4z+CtejoxCXZF9hOP2gbz/H/GBbIMcthfwrr+fDPvh5AZ9J3EIB6TQFlWHp6Bq1VWCi aq6G4nXIeCx7PdT3CkfnAqUxs+uBA7mQzNsBOsCWh3sg5AvtC/DXQpHDav9HqGa6rBB2 XTGxfeYoxlr+2h0ma6mdnUTKoJUFBlvuJ3tov/Lqw55hiH+S5J4R88kCWIU0ie74BbCN 0tdw== X-Gm-Message-State: APjAAAV4Ch+TcT/AiDo0xqICzMZ+yew2oYVSsjSlPBVXwmhYqTWdxJCb aR7Ogk79u5s2LmGQseq87zU= X-Google-Smtp-Source: APXvYqzxdgx2PyqP0uoz08nDav9ohVyQ89hbhCxYHWoLhlq0p/mkaLuoFY0FERTI1/fBsfJd9vjT+g== X-Received: by 2002:a5d:5012:: with SMTP id e18mr13046963wrt.166.1564338574954; Sun, 28 Jul 2019 11:29:34 -0700 (PDT) Received: from p200300dd67126429397d7db45608eb5e.dip0.t-ipconnect.de (p200300DD67126429397D7DB45608EB5E.dip0.t-ipconnect.de. [2003:dd:6712:6429:397d:7db4:5608:eb5e]) by smtp.gmail.com with ESMTPSA id z25sm62527334wmf.38.2019.07.28.11.29.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jul 2019 11:29:34 -0700 (PDT) From: Tamas Blummer Message-Id: <78653C43-3766-4118-8C6A-8B073E7B8ECB@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C25F4EE1-C208-444E-9370-E009C4CC78EE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 28 Jul 2019 20:29:34 +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 18:29:37 -0000 --Apple-Mail=_C25F4EE1-C208-444E-9370-E009C4CC78EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In summary I see three mechansims of making use costly: 1. burn 2. time locked funds, locker will incure opportunity cost 3. proven coin age, holder did incure opportunity cost I dislike burn as usage of a service is infinite while coin supply is = finite. I prefer time locked funds over coin age as locked funds do not need = proof of unspentness, they can not be spent. Therefore time locked funds can be = sufficiently proven with SPV. The user of the service could post SPV proof with the = request. 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=_C25F4EE1-C208-444E-9370-E009C4CC78EE 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----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl096Y4ACgkQ9nKRxRdx ORyM4Qf+KZXFzsqK5XPB083VUB7uKfyAqxRQXLfwNiHaBriI5nw7szmDd0pgdPW4 3+doN5/QYW0GHJALZUcDwnsWbaQhdlCwFmZnW3OZPXRhBywdyIctMhnkBrgRsEKP gfAIuoMM+YAJXdSZScdQp//APYU7C/tGf3V+vK6i9ProSZS1JSv2xwQtv/Ojiidf X0eF3kLPHKhH847Wi729qIRu6/qJNDIm2pFMutBS8HWJtAnCDkJfv9WxA/1eE5ZN gsBpYah6yG20OuLuSXHVK5nuJJ/huT4Ky+uo3b+ao43XMlxrc6lzMc3znORiGq0h +TUa0OoOA2ttxKii9y0iRQVKUye64Q== =Fyo9 -----END PGP SIGNATURE----- --Apple-Mail=_C25F4EE1-C208-444E-9370-E009C4CC78EE--