public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: Mike Hearn <mike@plan99.net>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol changes
Date: Thu, 11 Aug 2011 18:24:42 +0100	[thread overview]
Message-ID: <201108111824.42807.andyparkins@gmail.com> (raw)
In-Reply-To: <CANEZrP2hvYst92u22c_41e9=izPCP7uv-RzVM4XSt7gxC99D0A@mail.gmail.com>

On Thursday 11 August 2011 17:17:23 Mike Hearn wrote:

> This thread is getting off-topic so I changed the subject.

Fair enough.

> > The benefit I'm aiming at is to imagine a thin client that has done a
> > fast startup and only downloaded the headers.
> 
> OK. A better way is tx filtering, as discussed here:
> 
>    http://bitcointalk.org/?topic=7972.0
> 
> The reason is you want to only get the transactions+merkle branches
> relevant to you, otherwise cost is still O(system activity) not O(your
> activity) as blocks get bigger, even if you don't download every
> block.

Well okay; it seems to me that that is considerably bigger task, and I'm not 
sure how likely that is to appear.  But that sounds workable, since my 
feature request is simply this filtering system with the filter set to 
"ALL"; so I can hardly complain about that.

> > The sequence number (and perhaps I've misunderstood) allows me to
> > replace a transaction I've already submitted
> 
> Yes, but it's more complex than that.

 ... good stuff removed for brevity ...

> sequence number than mine - so we establish a kind of chain. Nobody
> can rewind the transaction to an earlier point, but anyone can update
> it within the parameters established by the SIGHASH flags on the
> others signatures.

I can't say I see what the point of all that added complexity is, contracts 
are usually more than just financial, and the ability to pick a slightly 
different set of source inputs doesn't seem like a hugely useful feature; 
but I'm willing to accept someone thinks it is a good idea and leave it at 
that.  I withdraw my "move sequence number" feature request.

> You can't change anything about the inputs beyond scripts this way.
> The transaction still has to connect to the same outputs as before,
> and thus import the same amount of value.

What then allows the contract out of the memory pool into a chain?  The 
locktime?  No, no, forget it... I don't want to open a new can of worms.


Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com



  reply	other threads:[~2011-08-11 17:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-11 16:17 [Bitcoin-development] Protocol changes Mike Hearn
2011-08-11 17:24 ` Andy Parkins [this message]
2011-08-11 22:02   ` Mike Hearn

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=201108111824.42807.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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