From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 38877C002D for ; Mon, 16 May 2022 10:26:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 251CF41688 for ; Mon, 16 May 2022 10:26:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeTcUyX_F1Ac for ; Mon, 16 May 2022 10:26:53 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) by smtp4.osuosl.org (Postfix) with ESMTPS id F36D341596 for ; Mon, 16 May 2022 10:26:52 +0000 (UTC) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx0.riseup.net (Postfix) with ESMTPS id 4L1wR02Zctz9tD8 for ; Mon, 16 May 2022 03:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1652696812; bh=s/zzaEGVPQ6krh1ogF5tOiv++nQIJYLCMz5ZWRbUtYw=; h=Date:From:Subject:To:From; b=Q7NS6YLzkMbOu8blErSXPBKKdapLlZ8hQbfvxWSd3EhaaRMWS2geSXIKo4XEqmVbS wiZ+IQTu349IVqggPov0Uruhhm7f6P9luq68GLpsGCZLKefOjGyOucrmRfruNPoztV 41au2MvPbk+L61YKRAxF8Ehx+TPwMK0fy3SQxhaA= X-Riseup-User-ID: B97E42F984611F032376AE0285A11C6BB87B5A971D4CA76DD5EF585A4C3B3015 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4L1wQz6fP8z1yTD for ; Mon, 16 May 2022 03:26:51 -0700 (PDT) Message-ID: <21c0cdea-f929-b9a8-baa6-e33eb2cee80f@riseup.net> Date: Mon, 16 May 2022 11:26:45 +0100 MIME-Version: 1.0 Content-Language: en-US From: Chris Belcher To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [bitcoin-dev] Improving chaumian ecash and sidechains with fidelity bond federations X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2022 10:26:55 -0000 Hello list, Fidelity bonds could be used to help create trust-minimized federations that are needed for things like chaumian ecash servers or sidechains. From what I've seen until now, people working on chaumian ecash or sidechains say that the federation controlling the multisig keys will be based on some kind of reputation. Perhaps it will be some pseudonymous nyms that have built up a good reputation over a long time. I suggest another option is to use fidelity bonds to decide who gets to control the multisig keys. Fidelity bonds are a way to deliberately sacrifice bitcoin value in a way that can be proven to a third party. In practice this is done by sending bitcoins to an address which is time-locked using the OP_CHECKTIMELOCKVERIFY opcode. The redeemscript and UTXO, along with a signature, can be shown to anyone to prove that the sacrifice happened. This system has already been deployed in JoinMarket since August 2021, and at the time of writing about 600 btc have been locked up, some for several years. The whole scheme is similar in some ways to PoW that bitcoin itself uses to avoid sybil attacks when solving the double spend problem. It's important to understand what is the value-add of fidelity bonds and what it isn't. Fidelity bonds don't solve the trust issue, as someone with a big fidelity bond could still steal funds from the ecash server or sidechain using multisig keys they control. Such systems will always be custodial. Rather, fidelity bonds strongly incentivize that the different fidelity bond owners are actually different people. That might be exactly the kind of thing needed for distributing the keys of big multisigs, especially now that taproot allows us to create very big multisig schemes. This happens because the value of a fidelity bond is calculated as a greater-than-linear power of the bitcoin sacrifice. So for example if the power was 2, and someone sacrificed 5 bitcoins of value, their fidelity bond would be worth 5 x 5 = 25. If instead they sacrificed 6 bitcoins their fidelity bond would be worth 6 x 6 = 36. This superlinear power is what creates a strong incentive for the different fidelity bonds to actually be controlled by different people, because anyone behaving rationally will put all their bitcoins into just one fidelity, not split them up over many bonds. As a sybil attacker needs to distribute their bitcoins over many different bonds, they are mathematically punished. The fidelity bond system achieves this without revealing anything much about those people's identities. Another value-add of fidelity bonds is they are very much in keeping with the cypherpunk ethos, as anyone can create a fidelity bond and advertise it in the market. As the bitcoins can be mixed with coinjoin before and after sending to the timelocked address, the scheme doesn't have to be linked to any identity. Only money talks; not reputation, political power or geographical power. I don't know yet exactly the details of how such a scheme would work, maybe something like each fidelity bond owner creates a key in the multisig scheme, and transaction fees from the sidechain or ecash server are divided amongst the fidelity bonds in proportion to their fidelity bond value. Regards CB