š
Original date posted:2016-09-21
š Original message:On Tuesday 20 Sep 2016 21:31:47 Luke Dashjr wrote:
> On Tuesday, September 20, 2016 5:15:45 PM Tom via bitcoin-dev wrote:
> > As the title suggests, I would like to formally request the assignment of
> > a
> > BIP number for my FT spec.
>
> Please open a pull request on the bitcoin/bips repo after this has been
> discussed a bit on the ML.
> It seems from the later comments, that it is the end of the transaction as a
> whole. Yet a separator between the txid and non-txid data would probably be
> valuable, rather than hard-coding txid to skip signature types (which may
> be unknown to old nodes, when extended).
>
> > The OP_CHECKSIG is the most well known and, as its name implies, it
> > validates a signature.
> > In the new version of 'script' (version 2) the data that is signed is
> > changed to be equivalent to the transaction-id. This is a massive
> > simplification and also the only change between version 1 and version 2 of
> > script.
>
> This seems to be a major regression. What is the replacement for
> SIGHASH_SINGLE and SIGHASH_ANYONECANPAY?
How is this a regression? Can you explain what functionality is lost please?
> When revising OP_CHECKSIG, it would also be nice to add the ability to use
> *only* a hash of the prevout's scriptPubKey in the input, so that *when* the
> prevtx is malleated, the spending one remains valid. (This use case is
> currently not supported.)
Maybe for the next version of script :)
> > Notice that the token ScriptVersion is currently not allowed
> What happens if I put ScriptVersion=1 here?
The transaction is invalid...
> > === Block-malleability ===
> >
> > For this reason the merkle tree is extended to include (append) the hash
> > of
> > the v4 transactions (and those alone) where the hash is taken over a
>
> > data-blob that is build up from:
>
> How should nodes know where in the merkle-tree the txids end, and the
> v4hashes begin?
Because the txid based ones are not going away. So the number of transactions
in the block can be used to determine when the pure tx-id segment stops and
when the v4 hashes begin. Then its up to the client to rebuild the tree from
that list based on the larger input set to get the same root-node.
I clarified many little things on my clone of the bips, check there if you
want to see the details.
Tom [ARCHIVE] /
npub1h3ā¦8z4k5
2023-06-07 17:53:25
in reply to nevent1qā¦8p2q
Author Public Key
npub1h394c0pkdum0jw4rufslt3ur9m9c2ym4x7a0t68spfpjr6zlq3msu8z4k5Published at
2023-06-07 17:53:25Event JSON
{
"id": "5e1b410426c562c1aee3c9e56dc8b6b8ecbf28344fee08a9d853ef672ad47fb2",
"pubkey": "bc4b5c3c366f36f93aa3e261f5c7832ecb85137537baf5e8f00a4321e85f0477",
"created_at": 1686160405,
"kind": 1,
"tags": [
[
"e",
"1a569d98e0e6ce5c9d61181fddad681419ffdb691b73a42ccb4919035df06596",
"",
"root"
],
[
"e",
"c98867732b248b876406614fb2bd53a763285c4ec5e2c32268b15aa84204e5dc",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "š
Original date posted:2016-09-21\nš Original message:On Tuesday 20 Sep 2016 21:31:47 Luke Dashjr wrote:\n\u003e On Tuesday, September 20, 2016 5:15:45 PM Tom via bitcoin-dev wrote:\n\u003e \u003e As the title suggests, I would like to formally request the assignment of\n\u003e \u003e a\n\u003e \u003e BIP number for my FT spec.\n\u003e \n\u003e Please open a pull request on the bitcoin/bips repo after this has been\n\u003e discussed a bit on the ML.\n\n\u003e It seems from the later comments, that it is the end of the transaction as a\n\u003e whole. Yet a separator between the txid and non-txid data would probably be\n\u003e valuable, rather than hard-coding txid to skip signature types (which may\n\u003e be unknown to old nodes, when extended).\n\u003e \n\u003e \u003e The OP_CHECKSIG is the most well known and, as its name implies, it\n\u003e \u003e validates a signature.\n\u003e \u003e In the new version of 'script' (version 2) the data that is signed is\n\u003e \u003e changed to be equivalent to the transaction-id. This is a massive\n\u003e \u003e simplification and also the only change between version 1 and version 2 of\n\u003e \u003e script.\n\u003e \n\u003e This seems to be a major regression. What is the replacement for\n\u003e SIGHASH_SINGLE and SIGHASH_ANYONECANPAY?\n\nHow is this a regression? Can you explain what functionality is lost please?\n\n\u003e When revising OP_CHECKSIG, it would also be nice to add the ability to use\n\u003e *only* a hash of the prevout's scriptPubKey in the input, so that *when* the\n\u003e prevtx is malleated, the spending one remains valid. (This use case is\n\u003e currently not supported.)\n\nMaybe for the next version of script :)\n \n\u003e \u003e Notice that the token ScriptVersion is currently not allowed\n\u003e What happens if I put ScriptVersion=1 here?\n\nThe transaction is invalid...\n \n\u003e \u003e === Block-malleability ===\n\u003e \u003e \n\u003e \u003e For this reason the merkle tree is extended to include (append) the hash\n\u003e \u003e of\n\u003e \u003e the v4 transactions (and those alone) where the hash is taken over a\n\u003e \n\u003e \u003e data-blob that is build up from:\n\u003e\n\u003e How should nodes know where in the merkle-tree the txids end, and the\n\u003e v4hashes begin?\n\nBecause the txid based ones are not going away. So the number of transactions \nin the block can be used to determine when the pure tx-id segment stops and \nwhen the v4 hashes begin. Then its up to the client to rebuild the tree from \nthat list based on the larger input set to get the same root-node.\n\nI clarified many little things on my clone of the bips, check there if you \nwant to see the details.",
"sig": "219ba183f745cd6d7c6d47f618639846998c696eeb548d4bdfb6085b3980aa10e18585e757fd96e363ebc8de9add247f8d61460e3548a0d5255185ecd5857528"
}