* [Bitcoin-development] Protocol changes
@ 2011-08-11 16:17 Mike Hearn
2011-08-11 17:24 ` Andy Parkins
0 siblings, 1 reply; 3+ messages in thread
From: Mike Hearn @ 2011-08-11 16:17 UTC (permalink / raw)
To: Andy Parkins; +Cc: bitcoin-development
This thread is getting off-topic so I changed the subject.
> 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.
> 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.
Some contract protocols require one party in a set to be able to
re-issue transactions without interacting with the other parties. The
reason is that each input can come from a different person. If the
sequence number was a property of the transaction, updating it would
either require all participants to re-sign the transaction, or for the
signatures to not cover the sequence number at all.
With seqnums on the inputs, I can create a newer version of the
transaction by just resigning my input with a higher sequence number.
This is defined by IsNewerThan(). Note that my options here are
limited - I can't create an arbitrarily different version of the
transaction without invalidating all the other input signatures. If I
own all the inputs, no problem. If some are owned by others, what I
can change is defined by the SIGHASH flags. To replace this tx in the
memory pool requires others to re-sign their input with a higher
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.
These features all combine together to allow for particular types of
contracts that take place on the negotiating table of the networks
memory pool. For instance, if you are taking part and then decide you
don't wish to continue, you can set the output that's in the same
position as your input to reassign all the money you put in back to
you, sign the input with SIGHASH_SINGLE and broadcast with nSequence
set to UINT_MAX. Now the transaction is still valid but is a no-op
from your perspective. Note that once you've done this, you've bowed
out of the negotiation completely because you can't replace the
transaction anymore.
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] Protocol changes
2011-08-11 16:17 [Bitcoin-development] Protocol changes Mike Hearn
@ 2011-08-11 17:24 ` Andy Parkins
2011-08-11 22:02 ` Mike Hearn
0 siblings, 1 reply; 3+ messages in thread
From: Andy Parkins @ 2011-08-11 17:24 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] Protocol changes
2011-08-11 17:24 ` Andy Parkins
@ 2011-08-11 22:02 ` Mike Hearn
0 siblings, 0 replies; 3+ messages in thread
From: Mike Hearn @ 2011-08-11 22:02 UTC (permalink / raw)
To: Andy Parkins; +Cc: bitcoin-development
> I can't say I see what the point of all that added complexity is, contracts
> are usually more than just financial
The term "contract" is sort of misleading, but there isn't a better
word for it. Satoshi called them contracts so that's what I call them
too.
http://en.bitcoin.it/wiki/Contracts
The point is to allow for lower trust in certain types of
transactions. For instance, consider Kickstarter. They allow people to
club together to fund the creation of new things, typically indie
movies and games. The problem is you need this trusted middleman to
collect peoples pledges and aggregate them. That adds fees, etc. With
contracts it can be done entirely with software, all the artist/game
programmer would need is to run some software on their website.
> 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.
;)
Lock time or if every sequence number is UINT_MAX.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-08-11 22:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-11 16:17 [Bitcoin-development] Protocol changes Mike Hearn
2011-08-11 17:24 ` Andy Parkins
2011-08-11 22:02 ` Mike Hearn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox