š
Original date posted:2015-05-28
š Original message: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 0xFFFFFFFF 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
000000000000000008464a6a19387029fa99edace15996d06a6343a8345d6167
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/b3fb4c20/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 15:35:51
in reply to nevent1qā¦t7jz
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 15:35:51Event JSON
{
"id": "b7521f7db29e187c64d2ad9eb39114d3bdbddcfbc25a4fbda95cd3e2491a2889",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686152151,
"kind": 1,
"tags": [
[
"e",
"c199e20b6969bf72586a0429657926889637a0b69d122308bc0c76c04451abb2",
"",
"root"
],
[
"e",
"dfa13513769808a2df418f0e016ee5140a3c75e95ebcc5c5e5b3f7b8a6e97317",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "š
Original date posted:2015-05-28\nš Original message:On Thu, May 28, 2015 at 11:30:18AM +0100, Tier Nolan wrote:\n\u003e Can you update it so that it only applies to transactions with version\n\u003e number 3 and higher. Changing the meaning of a field is exactly what the\n\u003e version numbers are for.\n\u003e \n\u003e You could even decode version 3 transactions like that.\n\u003e \n\u003e Version 3 transactions have a sequence number of 0xFFFFFFFF and the\n\u003e sequence number field is re-purposed for relative lock time.\n\u003e \n\u003e This means that legacy transactions that have already been signed but have\n\u003e a locktime in the future will still be able to enter the blockchain\n\u003e (without having to wait significantly longer than expected).\n\nFor that matter, we probably don't want to treat this as a *version*\nchange, but rather a *feature* flag. For instance, nSequence is\npotentially useful for co-ordinating multiple signatures to ensure they\ncan only be used in certain combinations, a use-case not neccesarily\ncompatible with this idea of a relative lock. Similarly it's potentially\nuseful for dealing with malleability.\n\nnSequence is currently the *only* thing in CTxIn's that the signature\nsigns that can be freely changed; I won't be surprised if we find other\nuses for it.\n\nOf course, all of the above is assuming this proposal is useful; that's\nnot clear to me yet and won't be without fleshed out examples.\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000008464a6a19387029fa99edace15996d06a6343a8345d6167\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/b3fb4c20/attachment.sig\u003e",
"sig": "694b890cc0c8e3b09875a2eed99bb6b000149d7895e07ce00c6e873646fabde2418cad36982dd62a7c3812a903d91fbdbb6896a6d27a2432991275bc80fb4bcb"
}