Mark Friedenbach [ARCHIVE] on Nostr: š Original date posted:2015-08-08 š Original message:It is not a bug that you ...
š
Original date posted:2015-08-08
š Original message:It is not a bug that you are unable to selectively choose these features
with higher version numbers. The version selection is in there at all
because there is a possibility that there exists already signed
transactions which would violate these new rules. We wouldn't want these
transactions to become unspendable. However moving forward there is no
reason to selectively pick and choose which of these new consensus rules
you want to apply your transaction.
On Aug 8, 2015 11:51 AM, "jl2012 via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> BIP68 rules and some of the BIP62 rules are applied only if the tx version
> is >=2 and >=3 respectively. Therefore, it is not possible to create a tx
> which follows BIP62 but not BIP68. If we introduce v4 tx later, BIP62 and
> BIP68 will all become mandatory.
>
> Some rules, e.g. "scriptPubKey evaluation will be required to result in a
> single non-zero value" in BIP62, will cause trouble when we try to
> introduce a new script system with softfork.
>
> I suggest to divide the tx version field into 2 parts: the higher 4 bits
> and lower 28 bits.
>
> BIP62 is active for a tx if its highest bits are 0000, and the second
> lowest bit is 1.
>
> BIP68 is active for a tx if its highest bits are 0000, and the third
> lowest bit is 1.
>
> So it will be easier for us to re-purpose the nSequence, or to take
> advantage of malleability in the future. If this is adopted, the nSequence
> high bit requirement in BIP68 becomes unnecessary as we could easily switch
> it off.
>
> The low bits will allow 28 independent BIPs and should be ample for many
> years. When they are exhausted, we can switch the high bits to a different
> number (1-15) and redefine the meaning of low bits. By that time, some of
> the 28 BIPs might have become obsoleted or could be merged.
>
> (I'm not sure if there are other draft BIPs with similar interpretation of
> tx version but the comments above should also apply to them)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150808/7ea9711a/attachment-0001.html>;
š Original message:It is not a bug that you are unable to selectively choose these features
with higher version numbers. The version selection is in there at all
because there is a possibility that there exists already signed
transactions which would violate these new rules. We wouldn't want these
transactions to become unspendable. However moving forward there is no
reason to selectively pick and choose which of these new consensus rules
you want to apply your transaction.
On Aug 8, 2015 11:51 AM, "jl2012 via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> BIP68 rules and some of the BIP62 rules are applied only if the tx version
> is >=2 and >=3 respectively. Therefore, it is not possible to create a tx
> which follows BIP62 but not BIP68. If we introduce v4 tx later, BIP62 and
> BIP68 will all become mandatory.
>
> Some rules, e.g. "scriptPubKey evaluation will be required to result in a
> single non-zero value" in BIP62, will cause trouble when we try to
> introduce a new script system with softfork.
>
> I suggest to divide the tx version field into 2 parts: the higher 4 bits
> and lower 28 bits.
>
> BIP62 is active for a tx if its highest bits are 0000, and the second
> lowest bit is 1.
>
> BIP68 is active for a tx if its highest bits are 0000, and the third
> lowest bit is 1.
>
> So it will be easier for us to re-purpose the nSequence, or to take
> advantage of malleability in the future. If this is adopted, the nSequence
> high bit requirement in BIP68 becomes unnecessary as we could easily switch
> it off.
>
> The low bits will allow 28 independent BIPs and should be ample for many
> years. When they are exhausted, we can switch the high bits to a different
> number (1-15) and redefine the meaning of low bits. By that time, some of
> the 28 BIPs might have become obsoleted or could be merged.
>
> (I'm not sure if there are other draft BIPs with similar interpretation of
> tx version but the comments above should also apply to them)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150808/7ea9711a/attachment-0001.html>;