Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
Tier Nolan tier.no...@gmail.com 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 (and most would set it lower). For long term, the absolute version is just as good. That depends on use cases. You can't take step 4 until 3 months after step 3 has completed doesn't seem useful. Lightning channels want them exactly like this to revoke old transactions, which could be ancient on long-lived channels. Cheers, Rusty. -- ___ 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
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 sequence number field is re-purposed for relative lock time. This means that legacy transactions that have already been signed but have a locktime in the future will still be able to enter the blockchain (without having to wait significantly longer than expected). On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach m...@friedenbach.org wrote: 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/tree/sequencenumbers On Wed, May 27, 2015 at 10:39 AM, Mike Hearn m...@plan99.net wrote: 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 by miners before the later transactions mature. Did I fail in some way to capture that original intent? Right, but the original protocol allowed for e.g. millions of revisions of the transaction, hence for high frequency trading (that's actually how Satoshi originally explained it to me - as a way to do HFT - back then the channel concept didn't exist). As you point out, with a careful construction of channels you should only need to bump the sequence number when the channel reverses direction. If your app only needs to do that rarely, it's a fine approach.And your proposal does sounds better than sequence numbers being useless like at the moment. I'm just wondering if we can get back to the original somehow or at least leave a path open to it, as it seems to be a superset of all other proposals, features-wise. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
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. Version 3 transactions have a sequence number of 0x and the sequence number field is re-purposed for relative lock time. This means that legacy transactions that have already been signed but have a locktime in the future will still be able to enter the blockchain (without having to wait significantly longer than expected). For that matter, we probably don't want to treat this as a *version* change, but rather a *feature* flag. For instance, nSequence is potentially useful for co-ordinating multiple signatures to ensure they can only be used in certain combinations, a use-case not neccesarily compatible with this idea of a relative lock. Similarly it's potentially useful for dealing with malleability. nSequence is currently the *only* thing in CTxIn's that the signature signs that can be freely changed; I won't be surprised if we find other uses for it. Of course, all of the above is assuming this proposal is useful; that's not clear to me yet and won't be without fleshed out examples. -- 'peter'[:-1]@petertodd.org 08464a6a19387029fa99edace15996d06a6343a8345d6167 signature.asc Description: Digital signature -- ___ 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
On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach m...@friedenbach.org 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 (since there is no restrictions on sequence numbers). This makes it a soft fork. That doesn't change the fact that you are changing what a field in the transaction represents. You could say that the sequence number is no longer encoded in the serialization, it is assumed to be 0x for all version 2+ transactions and the relative locktime is a whole new field that is the same size (and position). I think keeping some of the bytes for other uses is a good idea. The entire top 2 bytes could be ignored when working out relative locktime verify. That leaves them fully free to be set to anything. It could be that if the MSB of the bottom 2 bytes is set, then that activates the rule and the top 2 bytes are ignored. Are there any use-cases which need a RLTV of more than 8191 blocks delay (that can't be covered by the absolute version)? -- ___ 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
On Wed, May 27, 2015 at 08:18:52AM +, Gregory Maxwell wrote: On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org 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 the construction gives the sequence numbers a rational meaning, they count down the earliest position a transaction can be included. (e.g. the highest possible sequence number can be included any time the inputs are included) the next lower sequence number can only be included one block later than the input its assigned to is included, the next lower one block beyond that. All consensus enforced. A miner could opt to not include the higher sequence number (which is the only one of the set which it _can_ include) it the hopes of collecting more fees later on the next block, similar to how someone could ignore an eligible locked transaction in the hopes that a future double spend will be more profitable (and that it'll enjoy that profit) but in both cases it must take nothing at all this block, and risk being cut off by someone else (and, of course, nothing requires users use sequence numbers only one apart...). I understand that part. I'm just saying it's not clear to me what's the functional difference in practice between it and having both parties sign a decreasing absolute nLockTime. For instance, you and I could setup a payment channel using the following transaction t0: 1.0 BTC: PT - 1.0 BTC: PT (GM || expiry CLTV) 1.0 BTC: GM - 1.0 BTC: GM (PT || expiry CLTV) After expiry both of us are guaranteed to get our funds back regardless. I can then give you funds by signing my part of t1a: t0.vout[0] PT sig blank - 0.5 BTC: PT t0.vout[1] blank PT sig - 1.5 BTC: GM nLockTime = expiry - 1 You can then give me funds with t1b: t0.vout[0] blank GM sig - 1.5 BTC: PT t0.vout[1] GM sig blank - 0.5 BTC: GM nLockTime = expiry - 2 etc. etc. We can close the channel by signing a non-nLockTime'd tx at any time. If you don't co-operate, I have to wait, and hope I get my tx mined before you get yours. What I'm not seeing is how the relative nLockTime that nSequence provides fundamentally changes any of this. -- 'peter'[:-1]@petertodd.org 01643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6 signature.asc Description: Digital signature -- ___ 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
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 HFT between any set of parties. As it happens, this cannot be made safe in the bitcoin protocol as deployed today, as there is no enforcement of the rule that miners include the most recent transaction in their blocks. Safe is relative - this is the same logic the original replace-by-fee argument uses. There's no enforcement that miners use any particular ordering of transactions. 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 resource scheduling and update flood damping are implemented. That way people can try it out and if miners are breaking things too frequently by ignoring the chronological ordering people can abandon protocols that rely on it, and if they aren't they can proceed and benefit from the greater flexibility. -- ___ 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
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 Maxwell gmaxw...@gmail.com wrote: On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org 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 the construction gives the sequence numbers a rational meaning, they count down the earliest position a transaction can be included. (e.g. the highest possible sequence number can be included any time the inputs are included) the next lower sequence number can only be included one block later than the input its assigned to is included, the next lower one block beyond that. All consensus enforced. A miner could opt to not include the higher sequence number (which is the only one of the set which it _can_ include) it the hopes of collecting more fees later on the next block, similar to how someone could ignore an eligible locked transaction in the hopes that a future double spend will be more profitable (and that it'll enjoy that profit) but in both cases it must take nothing at all this block, and risk being cut off by someone else (and, of course, nothing requires users use sequence numbers only one apart...). It makes sequence numbers work exactly like you'd expect-- within the bounds of whats possible in a decentralized system. At the same time, all it is ... is relative nlocktime. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org 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 the construction gives the sequence numbers a rational meaning, they count down the earliest position a transaction can be included. (e.g. the highest possible sequence number can be included any time the inputs are included) the next lower sequence number can only be included one block later than the input its assigned to is included, the next lower one block beyond that. All consensus enforced. A miner could opt to not include the higher sequence number (which is the only one of the set which it _can_ include) it the hopes of collecting more fees later on the next block, similar to how someone could ignore an eligible locked transaction in the hopes that a future double spend will be more profitable (and that it'll enjoy that profit) but in both cases it must take nothing at all this block, and risk being cut off by someone else (and, of course, nothing requires users use sequence numbers only one apart...). It makes sequence numbers work exactly like you'd expect-- within the bounds of whats possible in a decentralized system. At the same time, all it is ... is relative nlocktime. -- ___ 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
On Wed, May 27, 2015 at 3:11 AM, Mike Hearn m...@plan99.net 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 resource scheduling and update flood damping are implemented. That way people can try it out and if miners are breaking things too frequently by ignoring the chronological ordering people can abandon protocols that rely on it, and if they aren't they can proceed and benefit from the greater flexibility. 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 by miners before the later transactions mature. Did I fail in some way to capture that original intent? -- ___ 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
On May 27, 2015 12:58 PM, Peter Todd p...@petertodd.org 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 nLockTime (which has been compared with the current height already when checking the script). In fact, the implementation could be simpler if the goal of maintaining the original nSequence semantics was ignored ( although not that simpler, but you wouldn't need to use ~ (bitwise not). I'm still not sure whether there should be 2 BIPs for this or just one. -- 'peter'[:-1]@petertodd.org 01643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
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 by miners before the later transactions mature. Did I fail in some way to capture that original intent? Right, but the original protocol allowed for e.g. millions of revisions of the transaction, hence for high frequency trading (that's actually how Satoshi originally explained it to me - as a way to do HFT - back then the channel concept didn't exist). As you point out, with a careful construction of channels you should only need to bump the sequence number when the channel reverses direction. If your app only needs to do that rarely, it's a fine approach.And your proposal does sounds better than sequence numbers being useless like at the moment. I'm just wondering if we can get back to the original somehow or at least leave a path open to it, as it seems to be a superset of all other proposals, features-wise. -- ___ 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
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 sign successive versions of a transaction, each time incrementing the sequence field by some amount. Relay nodes perform transaction replacement according to some policy rule making use of the sequence numbers, e.g. requiring sequence numbers in a replacement to be monotonically increasing. Can you provide a worked example of this in use? I think I see a major flaw, but I'd like to see a worked example first. Keep in mind that there's absolutely no reason to have pending transactions in mempools until we actually expect them to be mined. Equally this proposal is no more consensus enforcement than simply increasing the fee (and possibly decreasing the absolute nLockTime) for each replacement would be; increasing the fee for each mempool replacement is a hard requirement as an anti-DoS anyway. (this was all discussed on the mailing list two years ago when RBF was first proposed) -- 'peter'[:-1]@petertodd.org 0ec0c3a90baa52289171046469fe4a21dc5a0dac4cb758a9 signature.asc Description: Digital signature -- ___ 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
Please remove me from the mailing list 2015-05-27 3:50 GMT+02:00 Mark Friedenbach m...@friedenbach.org: 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 sequence field by some amount. Relay nodes perform transaction replacement according to some policy rule making use of the sequence numbers, e.g. requiring sequence numbers in a replacement to be monotonically increasing. As it happens, this cannot be made safe in the bitcoin protocol as deployed today, as there is no enforcement of the rule that miners include the most recent transaction in their blocks. As such, any protocol relying on a transaction replacement policy can be defeated by miners choosing not to follow that policy, which they may even be incentivised to do so (if older transactions provide higher fee per byte, for example). Transaction replacement is presently disabled in Bitcoin Core. These shortcomings can be fixed in an elegant way by giving sequence numbers new consensus-enforced semantics as a relative lock-time: if a sequence number is non-final (MAX_INT), its bitwise inverse is interpreted as either a relative height or time delta which is added to the height or median time of the block containing the output being spent to form a per-input lock-time. The lock-time of each input constructed in this manor, plus the nLockTime of the transaction itself if any input is non-final must be satisfied for a transaction to be valid. For example, a transaction with an txin.nSequence set to 0xff9b [== ~(uint32_t)100] is prevented by consensus rule from being selected for inclusion in a block until the 100th block following the one including the parent transaction referenced by that input. In this way one may construct, for example, a bidirectional micropayment channel where each change of direction increments sequence numbers to make the transaction become valid prior to any of the previously exchanged transactions. This also enables the discussed relative-form of CHECKLOCKTIMEVERIFY to be implemented in the same way: by checking transaction data only and not requiring contextual information like the block height or timestamp. An example implementation of this concept, as a policy change to the mempool processing of Bitcoin Core is available on github: https://github.com/maaku/bitcoin/tree/sequencenumbers -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
