Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.52 as permitted sender)
	client-ip=209.85.215.52; envelope-from=gmaxwell@gmail.com;
	helo=mail-la0-f52.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAE-z3OX7AppQeBcMBArccELQxnZBPNCefiRJvTt0gYYjxKAQuQ@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
	<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
	<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
	<CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@mail.gmail.com>
	<CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com>
	<CAAS2fgR1dRFVqhTNn55dZ6FS5zDM0aHs4ROPSD37hWwzLUKfCg@mail.gmail.com>
	<CANEZrP2t09bzmDkkWK3V2GpqEt54KhFnUQ8_u9ULMqniMaOA8Q@mail.gmail.com>
	<CAKuKjyV+FQs1goNK1uWXVg7ky4aGiROcTZ5idM3Ug2-+5bTc2w@mail.gmail.com>
	<CAAS2fgRWfcxYaLRY69=LE_+sDfYLNUTcimw4cE-2Byw7QonC=w@mail.gmail.com>
	<CAE-z3OX7AppQeBcMBArccELQxnZBPNCefiRJvTt0gYYjxKAQuQ@mail.gmail.com>
Date: Wed, 23 Apr 2014 14:39:26 -0700
Message-ID: <CAAS2fgQQyY=BGcM21EJiMkwBH0G5J57ahYEiD=bQTuprLHrHPA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
	Finney attacks
Precedence: list

On Wed, Apr 23, 2014 at 2:23 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
> An interesting experiment would be a transaction "proof of publication"
> chain.
>
> Each transaction would be added to that chain when it is received.  It co=
uld
> be merge mined with the main chain.
>
> If the size was limited, then it doesn't even require spam protection.
>
> Blocks could be "discouraged" if they have transactions which violate the
> ordering in that chain.  Miners could still decide which transactions the=
y
> include, but couldn't include transactions which are double spends.
>
> The locktime/final field could be used for transactions which want to be
> replaceable.
>
> The chain could use some of the fast block proposals.  For example, it co=
uld
> include orphans of a block when computing the block's POW.

You can see me proposing this kind of thing in a number of places (e.g.
http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt "p2pool
only forces the subsidy today, but the same mechnism could instead
force transactions.. e.g. to get you fast confirmation.", or
previously on BCT for the last couple years) but there are still
limits here:  If you don't follow the fast-confirmation share chain
you cannot mine third party transactions because you'll be at risk of
mining a double spend that gets you orphaned, or building on a prior
block that other miners have decided is bad.  This means that if the
latency or data rate requirements of the share chain are too large
relative to ordinary mining it may create some centralization
pressure.

That said, I think using a fast confirmation share-chain is much
better than decreasing block times and could be a very useful tool if
we believe that there are many applications which could be improved
with e.g. a 30 second or 1 minute interblock time.  Mostly my thinking
has been that these retail applications really want sub-second
confirmation, which can't reasonably be provided in this manner so I
didn't mention it in this thread.

One of the neat things about this is that you can introduce it totally
separately from Bitcoin without any consensus or approval from anyone
else=E2=80=94 E.g. P2pool builds such a chain today though it doesn't enfor=
ce
transactions.  It would immediately provide the useful service of
demonstrating that some chunk of hashpower was currently working on
including a particular set of transactions.  Once the details were
worked out it could be added as a soft-forking requirement to the
commonly run system.