Date: Thu, 08 Aug 2019 00:09:11 +0000
To: Dmitry Petukhov <dp@simplexum.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <jyEbDqD57bjrjd1QF72bLHmubrQxdc-WVqONP0gx-PjixLnQrLwWn9A2W_MkWwkTi_aJHSuUcLfxh2JnRp71110TtNNv8ZoDIhWAXFmuT5c=@protonmail.com>
In-Reply-To: <20190807201017.2a03b971@simplexum.com>
References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net>
	<20190731205018.10ed4302@simplexum.com>
	<ae32dcbb-c950-3b3f-22b9-d152d6b221cb@riseup.net>
	<20190802145057.7b81c597@simplexum.com>
	<ad501873-8912-765e-8df5-c9b0451fcd0a@riseup.net>
	<20190807015541.3d8aa849@simplexum.com>
	<20190807023742.73750ba3@simplexum.com>
	<483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net>
	<20190807201017.2a03b971@simplexum.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil
	attacks using fidelity bonds
Precedence: list

Good morning Dmitry,

> The first scheme - 'allow revocation of the whole bond by the key
> controlling even a single TXO in a bond' - might be more promising.

Is it?
I imagine any key can secretly be a MuSig or aggregated ECDSA key, with the=
 aggregator being a signatory.

>
> > I wonder if there's a cryptographic way to prove that muSig and
> > 2P-ECDSA have not been used to create a certain pubkey/signature.
>
> In the second scheme, to revoke/spoil the bond, the entity that
> controls one TXO participating in this bond needs to simply prove that
> it somehow controls/have the ability to spend that TXO.
>
> In shared ownership rent scheme that ZmnSCPxj described in [1],
> the 'TXO rentier' has a signed timelocked 'backout' transaction that
> spends the locked TXO, and assigns the reward to rentier.
>
> If we say that any transaction that spends any TXO in the bond
> (ignoring the timelock), invalidates the bond when presented to
> takers, then TXO rentier can revoke the bond by simply
> publishing this transaction (not to the blockchain, but by some other
> means so that takers can receive it).
>
> The transaction validity can be verified, with the relaxed rules that
> ignores the timelock. After it is verified, takers mark the whole
> bond as revoked and will not consider it when chosing makers.
>
> One inconvenience here is that takers need to store the
> data about revoked bonds. But it seems to me that there's no need
> for that information to be synchronized between the participants
> instantly. It is enougth for takers to get the revoked-set eventually.
>
> The rentier are still incentivized to not spoil the bond, to receive
> the profit. Their funds are locked anyway.
>
> But if the goal of the 'rentier' is to attack the attacker, the
> opportunity cost of these locked funds is the cost of the attack.
>
> If the renter rents TXOs from several entities to include in one bond,
> revocation by one rentier spoils whole bond, and the total loss for all
> participants is bigger than the oportunity cost of locked funds of a
> single rentier that made the revocation.
>
> The possibility of such revocation increases risk for the renter and
> would-be co-rentiers, and is likely limit the possible scale of such
> TXO-renting operation.

This is quite a clever solution.

Let me then attempt to break it.

It is possible to encrypt data in such a way that it requires sequential op=
erations in order to decrypt.
https://www.gwern.net/Self-decrypting-files

This basically allows us to encrypt some data in such a way that its decryp=
tion is timelocked, by requiring a large number of sequential operations to=
 decrypt.

It also seems to me (I am not a cryptographer) that it may be possible to p=
resent a ZKP that an encrypted text, encrypted using the above timelock dec=
ryption, is a signature of a particular message with a particular public ke=
y.

Thus, we can change the ritual to this:

1.  I contact two lessors to aggregate their coins into a larger UTXO and t=
hus break V^2.
2.  We create a funding transaction that pays to a locked bond address, wit=
h a pubkey equal to a MuSig among us.
    This spends the TXOs they want to lease out, as well as some of my fund=
s to be used for paying for rent.
    We do not sign this yet.
3.  We create a backout transaction that returns the bond to both lessors, =
plus their rent.
    We partly perform the MuSig ritual to sign this transaction, with me as=
 the last step.
4.  Instead of providing the completed signature to the lessors, I encrypt =
it using the above timelocked encryption.
    I provide this encryption and a zero-knowledge proof that I have actual=
ly completed the signature ritual correctly and that the timelocked-encrypt=
ed text has the signature as plaintext.
5.  The lessors now know they can acquire the signature by simply grinding =
the timelocked encryption.
    This allows them to recover their money by the appointed time.
6.  We then exchange signatures for the funding transaction and broadcast a=
nd confirm it.

Now, the lessors cannot provide a valid timelocked transaction, as they do =
*not* yet have a complete signature; thus they cannot snitch about my aggre=
gation of their funds.
At the same time, they know that the timelocked encryption allows them to e=
ventually get a complete signature and recover their funds.
I can defray this cost of processing by increasing my rent slightly.

Now of course we can just go one step further and also allow bonds to be sn=
itched by presenting the timelocked-encrypted text and the ZKP that it cont=
ains the signature for a timelocked transactions.
But it seems to me that there is more than one way to skin this particular =
cat, thus unless all ways to create provable timelocked encryptions are enu=
merable, it would be possible to get around.

(though of course it is dependent on a ZKP being possible for a timelocked =
encryption)

Finally, aggregation is still possible to insure by off-blockchain agreemen=
ts, possibly with legal consequences, and thus entities like exchanges migh=
t still be able to aggregate funds and acquire an undeservedly large weight=
 in the fidelity bond system.

Regards,
ZmnSCPxj