From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Dmitry Petukhov <dp@simplexum•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
Date: Thu, 08 Aug 2019 00:09:11 +0000 [thread overview]
Message-ID: <jyEbDqD57bjrjd1QF72bLHmubrQxdc-WVqONP0gx-PjixLnQrLwWn9A2W_MkWwkTi_aJHSuUcLfxh2JnRp71110TtNNv8ZoDIhWAXFmuT5c=@protonmail.com> (raw)
In-Reply-To: <20190807201017.2a03b971@simplexum.com>
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 operations 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 decryption 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 present a ZKP that an encrypted text, encrypted using the above timelock decryption, is a signature of a particular message with a particular public key.
Thus, we can change the ritual to this:
1. I contact two lessors to aggregate their coins into a larger UTXO and thus break V^2.
2. We create a funding transaction that pays to a locked bond address, with a pubkey equal to a MuSig among us.
This spends the TXOs they want to lease out, as well as some of my funds 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 actually completed the signature ritual correctly and that the timelocked-encrypted 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 and 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 aggregation of their funds.
At the same time, they know that the timelocked encryption allows them to eventually 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 snitched by presenting the timelocked-encrypted text and the ZKP that it contains 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 enumerable, 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 agreements, possibly with legal consequences, and thus entities like exchanges might still be able to aggregate funds and acquire an undeservedly large weight in the fidelity bond system.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2019-08-08 0:09 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-25 11:47 Chris Belcher
2019-07-26 8:10 ` Tamas Blummer
2019-07-26 9:38 ` Dmitry Petukhov
2019-07-30 21:39 ` Chris Belcher
2019-07-31 15:50 ` Dmitry Petukhov
2019-08-02 9:21 ` Chris Belcher
[not found] ` <20190802145057.7b81c597@simplexum.com>
2019-08-05 19:04 ` Chris Belcher
2019-08-06 1:51 ` Leo Wandersleb
2019-08-06 10:27 ` Chris Belcher
2019-08-06 13:07 ` Leo Wandersleb
2019-08-06 2:54 ` ZmnSCPxj
2019-08-06 20:55 ` Dmitry Petukhov
2019-08-06 21:37 ` Dmitry Petukhov
2019-08-06 23:33 ` ZmnSCPxj
2019-08-07 9:38 ` Chris Belcher
2019-08-07 11:20 ` ZmnSCPxj
2019-08-07 10:05 ` Chris Belcher
2019-08-07 11:35 ` ZmnSCPxj
2019-08-07 15:10 ` Dmitry Petukhov
2019-08-08 0:09 ` ZmnSCPxj [this message]
2019-08-08 9:35 ` ZmnSCPxj
2019-08-08 11:37 ` Dmitry Petukhov
2019-08-08 13:59 ` ZmnSCPxj
2019-08-08 20:06 ` Chris Belcher
2019-08-08 12:05 ` Dmitry Petukhov
2019-07-27 19:34 ` David A. Harding
2019-07-28 14:17 ` Tamas Blummer
2019-07-28 18:29 ` Tamas Blummer
2019-07-30 21:27 ` Chris Belcher
2019-07-31 17:59 ` David A. Harding
2019-08-02 14:24 ` Adam Gibson
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='jyEbDqD57bjrjd1QF72bLHmubrQxdc-WVqONP0gx-PjixLnQrLwWn9A2W_MkWwkTi_aJHSuUcLfxh2JnRp71110TtNNv8ZoDIhWAXFmuT5c=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dp@simplexum$(echo .)com \
/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