public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Chris Belcher <belcher@riseup•net>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
Date: Wed, 07 Aug 2019 11:35:34 +0000	[thread overview]
Message-ID: <IQE7dkcU-WE3QslZJ4uFyFafmFL_qAWJ_Us0nvwAGlyT44RDy9qUT7UZ2xDHyriIUzyYy-_dgGdTdJNKhx7zXlZkcPMfs2tHO1njLzHa-JY=@protonmail.com> (raw)
In-Reply-To: <483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net>

Good morning Dmitry,


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, August 7, 2019 6:05 PM, Chris Belcher via bitcoin-dev <bitcoin-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 safely stored without encryption by publishing to any cloud service --- others getting a copy of the signature does not let them change the signature to authorize 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 "sign this random nonce for me", but of note is that it would have to impose this 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, forming 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 need 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 for spying on CoinJoins.

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

Regards,
ZmnSCPxj


  reply	other threads:[~2019-08-07 11:35 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 [this message]
2019-08-07 15:10                     ` Dmitry Petukhov
2019-08-08  0:09                       ` ZmnSCPxj
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='IQE7dkcU-WE3QslZJ4uFyFafmFL_qAWJ_Us0nvwAGlyT44RDy9qUT7UZ2xDHyriIUzyYy-_dgGdTdJNKhx7zXlZkcPMfs2tHO1njLzHa-JY=@protonmail.com' \
    --to=zmnscpxj@protonmail$(echo .)com \
    --cc=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