Date: Fri, 23 Sep 2016 12:18:17 -0400
From: Peter Todd <pete@petertodd.org>
To: Luke Dashjr <luke@dashjr.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20160923161817.GA22926@fedora-21-dvm>
References: <201609230957.03138.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/"
Content-Disposition: inline
In-Reply-To: <201609230957.03138.luke@dashjr.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT
Precedence: list


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

On Fri, Sep 23, 2016 at 09:57:01AM +0000, Luke Dashjr via bitcoin-dev wrote:
> This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin=
=20
> scripting system to address reissuing bitcoin transactions when the coins=
 they=20
> spend have been conflicted/double-spent.
>=20
> https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
>=20
> Does this seem like a good idea/approach?

Your BIP is a bit confusing: you say "In some circumstances, users may wish=
 to
spend received bitcoins before they have confirmed on the blockchain", but =
what
you're really referring to isn't spending unconfirmed outputs - which
OP_CHECKBLOCKATHEIGHT can't protect - but rather spending outputs with a sm=
all
number of confirmations.

In the existing ecosystem, if multi-block reorgs were a regular event Bitco=
in
would be in a lot of trouble; since they're rare, advising wallet authors to
simply refuse to make transactions for some time after such a reorg may be a
better solution. After all, a multi-block reorg is a strong indication that
there's somehting very wrong with the network, and it'd be safer to stop us=
ing
Bitcoin for awhile until things settle down.

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

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

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

iQEcBAEBCAAGBQJX5VXGAAoJEGOZARBE6K+yngoH/2tMCMMyCztRuB78nHltFi2K
D90atoFGpVPlOq7DpLJl3EhXyJdoun9QqWWAyIMCz/efD5EAJptcbeN+dcVzIwYG
RvvBUqcZOTco319DHXv4OorAanVDzSutI7oM4sJ9P2ONyFSHPygEu3FCzybS5u6s
Cvp42GQRP2dKSt3u52NjCD4rU1LJWmqFJ7kMYTUGX0WXA9DZNDBryMv5g8LRGm6c
+QhOtKaVOGOhGub/52Gn7TCqoE5a2yJCsCxNT/fBAnnkuvHprElRgd+hMHEfHdlj
N541UV8uE8ehwyjUII553al1WKx6fiNJD1riq7W4rwiS3puHR9ChFLmDIxV4jtc=
=HOIj
-----END PGP SIGNATURE-----

--pWyiEgJYm5f9v55/--