From: Chris Belcher <belcher@riseup•net>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Improving chaumian ecash and sidechains with fidelity bond federations
Date: Mon, 16 May 2022 11:26:45 +0100 [thread overview]
Message-ID: <21c0cdea-f929-b9a8-baa6-e33eb2cee80f@riseup.net> (raw)
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
next reply other threads:[~2022-05-16 10:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 10:26 Chris Belcher [this message]
2022-05-16 11:26 ` 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=21c0cdea-f929-b9a8-baa6-e33eb2cee80f@riseup.net \
--to=belcher@riseup$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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