Date: Wed, 13 Sep 2017 06:03:28 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <greg@xiph.org>
Message-ID: <20170913100328.GA1613@savin.petertodd.org>
References: <CAAS2fgTGhCztV5bwLQj28_M7e=uzwbdF2Rum_7gmQGjhgxqLuQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <CAAS2fgTGhCztV5bwLQj28_M7e=uzwbdF2Rum_7gmQGjhgxqLuQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Minutia in CT for Bitcoin. Was: SF proposal:
 prohibit unspendable outputs with amount=0
Precedence: list


--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 13, 2017 at 09:39:28AM +0000, Gregory Maxwell wrote:
> On Wed, Sep 13, 2017 at 9:24 AM, Peter Todd via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 2) Spending CT-shielded outputs to unshielded outputs
> >
> > Here one or more CT-shielded outputs will be spent. Since their value i=
s zero,
> > we make up the difference by spending one or more outputs from the CT p=
ool,
> > with the change - if any - assigned to a CT-pool output.
>=20
> Can we solve the problem that pool inputs are gratuitously non-reorg
> safe, without creating something like a maturity limit for shielded to
> unshielded?

So to be clear, we have two versions of this problem:

1) CT signatures do *not* sign which pool input they're using

Here, obviously the inputs can be changed at will by miners. An implementat=
ion
could have the exact CT pool input be something miners add; the CT transact=
ions
broadcast on the P2P network wouldn't actually need them.


2) CT signatures *do* sign which pool input they're using

Wallets would pick the input at random. This is required if you want to hav=
e a
transaction spending both CT and legacy inputs. This reduces the reorg risk=
 to
double-spends. While double-spends are always a potential problem, the prob=
lem
is somewhat worse here, as even regular wallets are spending inputs that an=
yone
can choose to spend.


> So far the best I have is this:  Support unshielded coins in shielded
> space too. So the only time you transition out of the pool is paying
> to a legacy wallet.  If support were phased in (e.g. addresses that
> say you can pay me in the pool after its enabled), and the pool only
> used long after wallets supported getting payments in it, then this
> would be pretty rare and a maturity limit wouldn't be a big deal.

So basically, you're essentially observing that in the event that everyone =
uses
CT, this isn't actually a problem; you're allowing everyone to "use" CT, by
trying to allow even unshielded outputs to "use" it.

Which means by "unshielded output", what you *actuall* mean is creating a CT
transaction where the output - even though it's a zero-valued CT output - is
constructed such that the value is public information.

Or do you mean trying to have non-CT outputs in the pool somehow? I don't t=
hink
that makes sense, because the whole point of the pool is that the outputs i=
n it
are anyone-can-spend, and thus any CT transaction may spend them; which CT
transaction spends them gives no information about the ownership of the coi=
ns.
This is incompatible with anything but anyone-can-spend outputs.

> Can better be done?

Note that the order in which outputs in the pool are spent can be
deterministic. For example, you could say that each transaction must spend =
the
oldest outputs in the pool (that sum to the value needed). You could probab=
ly
come up with a scheme where the outputs that will be spent in the future in=
 the
event that the output is spent back to an unshielded output is fixed when t=
he
output was created, for example, by picking a random index. While this woul=
dn't
prevent all collisions, it'd may be possible to make reorgs relatively safe=
, by
constraining how miners could txids.

Specifically, you could imagine a scheme where if a given input set can onl=
y be
satisified by unspent pool outputs with index's >=3D i, then the miner woul=
d need
to have the ability to mine a conflicting transaction that also happened to
have the same pool output set. Given a sufficiently large set of pool outpu=
ts,
this may be an impractical attack most of the time.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZuQJsAAoJECSBQD2l8JH72K8H/2xNHvF9K+t0sWF+ALvKcs0g
o7cq64NpTduzkPRcfNk3ZjyuTJJ6wxwtOXVS+wRGq74OvcX8uCryAi4Ak8cfVn/X
Ya6opzbZ82/Wo82nK5oyq/VR250wxvVNrLFIqF28ywQf2FoIbzLWNwxTO7R97J4w
astJyZQYUcXdchKit2cFlJHZKGgW7yhlQ1xFj6iA0ZV+PdD2aY+nGWeiVkjUHQ6m
HWyEG0qiiWod5r31wdfKo8TL7CKRBEhxNgtkDtLrE6obZhdo0GD/w0YFV9irQoPA
48UBdu6azMgnIvMC+EOgioJw2kpT4qtOv0FjMuYvuUb+9iH16TmliheE/bo5qMM=
=CBVX
-----END PGP SIGNATURE-----

--W/nzBZO5zC0uMSeA--