Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Tier Nolan writes: > What are the use cases for relative lock time verify? I have 1 and I think > that is the kind of thing it is useful for. > > I think that most cases are just to guarantee that the other party has a > chance to react. This means that 8191 blocks should be more than enough > (

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Thu, May 28, 2015 at 5:22 PM, s7r wrote: > In this scenario, if channel is closed, Alice is the only one who can > take the coins back after a relative locktime of 150 blocks. Bob is not > able to do this. > Yes, Alice is assumed to be the one who funded the channel. It is a single direction

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On 5/28/2015 4:35 PM, Tier Nolan wrote: > On Thu, May 28, 2015 at 1:04 PM, Peter Todd > wrote: > > For that matter, we probably don't want to treat this as a *version* > change, but rather a *feature* flag. > > > I think it is still a version change. At th

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

What are the use cases for relative lock time verify? I have 1 and I think that is the kind of thing it is useful for. I think that most cases are just to guarantee that the other party has a chance to react. This means that 8191 blocks should be more than enough (and most would set it lower).

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Oh ok you mean a semantic difference for the purpose of explaining. It doesn't actually change the code. Regarding saving more bits, there really isn't much room if you consider time-based relative locktimes and long-lived channels on the order of a year or more. On Thu, May 28, 2015 at 8:18 AM,

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach wrote: > Why 3? Do we have a version 2? > I meant whatever the next version is, so you are right, it's version 2. > As for doing it in serialization, that would alter the txid making it a > hard fork change. > The change is backwards compatible (

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Why 3? Do we have a version 2? As for doing it in serialization, that would alter the txid making it a hard fork change. On May 28, 2015 03:30, "Tier Nolan" wrote: > Can you update it so that it only applies to transactions with version > number 3 and higher. Changing the meaning of a field is

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Thu, May 28, 2015 at 1:04 PM, Peter Todd wrote: > For that matter, we probably don't want to treat this as a *version* > change, but rather a *feature* flag. I think it is still a version change. At the moment, the 4 bytes refer to the sequence number and afterwards they mean something else

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Thu, May 28, 2015 at 11:30:18AM +0100, Tier Nolan wrote: > Can you update it so that it only applies to transactions with version > number 3 and higher. Changing the meaning of a field is exactly what the > version numbers are for. > > You could even decode version 3 transactions like that. >

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Can you update it so that it only applies to transactions with version number 3 and higher. Changing the meaning of a field is exactly what the version numbers are for. You could even decode version 3 transactions like that. Version 3 transactions have a sequence number of 0x and the seq

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Cool, thanks. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

I have no problem with modifying the proposal to have the most significant bit signal use of the nSequence field as a relative lock-time. That leaves a full 31 bits for experimentation when relative lock-time is not in use. I have adjusted the code appropriately: https://github.com/maaku/bitcoin/t

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

> > Mike, this proposal was purposefully constructed to maintain as well as > possible the semantics of Satoshi's original construction. Higher sequence > numbers -- chronologically later transactions -- are able to hit the chain > earlier, and therefore it can be reasonably argued will be selected

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On May 27, 2015 12:58 PM, "Peter Todd" wrote: > What I'm not seeing is how the relative nLockTime that nSequence > provides fundamentally changes any of this. This allows the implementation of a rcltv that doesn't make script depend on the current height, in a similar way that cltv uses the nLoc

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Wed, May 27, 2015 at 3:11 AM, Mike Hearn wrote: > > As I believe out of all proposed protocols Satoshi's is still the most > powerful, I would suggest that any change to the semantics on nSequence be > gated by a high bit or something, so the original meaning remains available > if/when resour

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Wed, May 27, 2015 at 08:18:52AM +, Gregory Maxwell wrote: > On Wed, May 27, 2015 at 7:47 AM, Peter Todd wrote: > > Equally this proposal is no more "consensus enforcement" than simply > > increasing the fee (and possibly decreasing the absolute nLockTime) for > > You've misunderstood it, I

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

> > Sequence numbers appear to have been originally intended as a mechanism > for transaction replacement within the context of multi-party transaction > construction, e.g. a micropayment channel. > Yes indeed they were. Satoshis mechanism was more general than micropayment channels and could do H

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

This could cause legacy transactions to become unspendable. A new transaction version number should be used to indicate the change of the field from sequence number to relative lock time. Legacy transactions should not have the rule applied to them. On Wed, May 27, 2015 at 9:18 AM, Gregory Maxw

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Wed, May 27, 2015 at 7:47 AM, Peter Todd wrote: > Equally this proposal is no more "consensus enforcement" than simply > increasing the fee (and possibly decreasing the absolute nLockTime) for You've misunderstood it, I think-- Functionally nlocktime but relative to each txin's height. But th

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Please remove me from the mailing list 2015-05-27 3:50 GMT+02:00 Mark Friedenbach : > Sequence numbers appear to have been originally intended as a mechanism > for transaction replacement within the context of multi-party transaction > construction, e.g. a micropayment channel. The idea is that a

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Tue, May 26, 2015 at 06:50:29PM -0700, Mark Friedenbach wrote: > Sequence numbers appear to have been originally intended as a mechanism for > transaction replacement within the context of multi-party transaction > construction, e.g. a micropayment channel. The idea is that a participant > can s

[Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Sequence numbers appear to have been originally intended as a mechanism for transaction replacement within the context of multi-party transaction construction, e.g. a micropayment channel. The idea is that a participant can sign successive versions of a transaction, each time incrementing the seque