Date: Wed, 07 Aug 2019 11:35:34 +0000
To: Chris Belcher <belcher@riseup.net>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <IQE7dkcU-WE3QslZJ4uFyFafmFL_qAWJ_Us0nvwAGlyT44RDy9qUT7UZ2xDHyriIUzyYy-_dgGdTdJNKhx7zXlZkcPMfs2tHO1njLzHa-JY=@protonmail.com>
In-Reply-To: <483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net>
References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net>
	<3c328312-2bdd-60d9-7425-8db620d09abb@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>
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,


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Wednesday, August 7, 2019 6:05 PM, Chris Belcher via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:

> These are very creative schemes. At the very least they would stop the
> easy mindless renting TXO method, where someone with coins on a hardware
> wallet simply creates a signature and copypastes it into a website to
> get free money. The workaround scheme with shared ownership of TXOs
> requires brand new wallets to be created and hodlers must trust the
> wallets enough to move their coins and hold them there for a long time.

Possibly not so much?
The wallet need only sign two things:

1.  The fidelity bond itself.
2.  The backout transaction.

Both can be done in a single session, then the private key involved can be =
erased permanently from memory.
Only the signature for the backout needs to be stored, and this can be safe=
ly stored without encryption by publishing to any cloud service --- others =
getting a copy of the signature does not let them change the signature to a=
uthorize a different transaction.
It would be enough to write the signing code in C and use special OS calls =
(which most languages higher than C do not expose) to allocate memory that =
will never be put in swap.
Then generate the private key using that memory, then clear it after usage =
before deallocating to the OS.
I believe `libsecp256k1` makes this easy.

Unless part of the bond process requires that the taker do a challenge "sig=
n this random nonce for me", but of note is that it would have to impose th=
is on all makers.
But if so, consider again this:

1.  There exists two non-spying makers with nearly-equal bond values.
2.  These makers need to keep their bond private keys in hot storage.
3.  I approach both makers and offer to aggregate their bond values, formin=
g a new bond with 4x the weight of their individual bonds, and split up the=
 increased earnings between us.
    This can be made noncustodial by use of smart contracts on Bitcoin.
4.  It is no different from the point of view of both makers: they still ne=
ed to keep their bond private keys in hot storage.
    But this way earns them more money than operating as non-spying makers.
5.  I earn not only the fees for JoinMarket, I also earn additional fees fo=
r spying on CoinJoins.

It still seems to me that adding the V^2 tweak weakens the bond system, not=
 strengthens it.

Regards,
ZmnSCPxj