From: Peter Todd <pete@petertodd•org>
To: "zaki@manian•org" <zaki@manian•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Building Blocks of the State Machine Approach to Consensus
Date: Tue, 21 Jun 2016 18:42:25 -0400 [thread overview]
Message-ID: <20160621224225.GA10422@fedora-21-dvm> (raw)
In-Reply-To: <CAJQ8TmBw3PdCYv=fsyiXMTNO_sHZEj__n0Rsra6id+ORxQworA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
On Mon, Jun 20, 2016 at 04:21:39PM +0000, zaki--- via bitcoin-dev wrote:
> Hi Peter,
>
> I didn't entirely understand the process of transaction linearization.
>
> What I see is a potential process where when the miner assembles the block,
> he strips all but one sigscript per tx. The selection of which sigscript
> is retained is determined by the random oracle. Is this is primary benefit
> you are suggesting?
>
> It appears to me that blocks still need to contain a list of full TX Input
> and Tx Outputs with your approach. Some of the description seems to
> indicate that there are opportunities to elide further data but it's
> unclear to me how.
I think you've misunderstood what I'm proposing. The state machine approach I
described doesn't necessarily require blocks or even miners to exist at all.
Rather, it assumes that a single-use seal primitive is available, and a random
beacon primitive for tx linearization, and then builds a system on top of those
primitives. Transaction data - the proofs that certain states have been reached
in the system - does not need to be broadcast publicly; if Alice wants to
convince Bob that she has given him money, the only person who needs that
transaction (and transactions prior to it in the tx history) is Bob.
So as to your question about miners assembling blocks, and what blocks contain:
there doesn't need to be blocks at all! Transaction history linearization is
something your wallet would do for you.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2016-06-21 22:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 8:56 Peter Todd
2016-06-20 13:26 ` Police Terror
2016-06-20 16:21 ` zaki
2016-06-21 22:42 ` Peter Todd [this message]
2016-06-23 11:21 ` Peter Todd
2016-06-20 22:28 ` Alex Mizrahi
2016-06-23 11:11 ` Peter Todd
2016-06-23 12:58 ` Alex Mizrahi
2016-06-24 22:23 ` Peter Todd
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=20160621224225.GA10422@fedora-21-dvm \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=zaki@manian$(echo .)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