ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-07-19 📝 Original message:Good morning Mike, > ...
📅 Original date posted:2019-07-19
📝 Original message:Good morning Mike,
> PubRef is not susceptible to malleability attacks because the blockchain is immutable.
This is not quite accurate.
While very old blocks are indeed immutable-in-practice, chain tips are not, and are often replaced.
At least specify that such data can only be referred to if buried under 100 blocks.
--
There are a number of other issues:
* It strongly encourages pubkey reuse, reducing privacy.
* There is a design-decision wherein a SCRIPT can only access data in the transaction that triggers its execution.
In particular, it cannot access data in the block the transaction is in, or in past blocks.
For example, `OP_CHECKLOCKTIMEVERIFY` does not check the blockheight of the block that the transaction is confirmed in, but instead checks only `nLockTime`, a field in the transaction.
* This lets us run SCRIPT in isolation on a transaction, exactly one time, when the transaction is about to be put into our mempool.
When a new block arrives, transactions in our mempool that are in the block do not need to have their SCRIPTs re-executed or re-validated.
> In order for a client to make use of the PUBREF operations they’ll need access to a database that look up public-keys and resolve their PUBREF index. A value can be resolved to an index with a hash-table lookup in O(1) constant time. Additionally, all instances of PUSHDATA can be indexed as an ordered list, resolution of a PUBREF index to the intended value would be an O(1) array lookup. Although the data needed to build and resolve public references is already included with every full node, additional computational effort is needed to build and maintain these indices - a tradeoff which provides smaller transaction sizes and relieving the need to store repetitive data on the blockchain.
This is not only necessary at the creator of the transaction --- it is also necessary at every validator.
In particular, consider existing pruning nodes, which cannot refer to previous block data.
We would need to have another new database containing every `PUSHDATA` in existence.
And existing pruning nodes would need to restart from genesis, as this database would not exist yet.
Regards,
ZmnSCPxj
📝 Original message:Good morning Mike,
> PubRef is not susceptible to malleability attacks because the blockchain is immutable.
This is not quite accurate.
While very old blocks are indeed immutable-in-practice, chain tips are not, and are often replaced.
At least specify that such data can only be referred to if buried under 100 blocks.
--
There are a number of other issues:
* It strongly encourages pubkey reuse, reducing privacy.
* There is a design-decision wherein a SCRIPT can only access data in the transaction that triggers its execution.
In particular, it cannot access data in the block the transaction is in, or in past blocks.
For example, `OP_CHECKLOCKTIMEVERIFY` does not check the blockheight of the block that the transaction is confirmed in, but instead checks only `nLockTime`, a field in the transaction.
* This lets us run SCRIPT in isolation on a transaction, exactly one time, when the transaction is about to be put into our mempool.
When a new block arrives, transactions in our mempool that are in the block do not need to have their SCRIPTs re-executed or re-validated.
> In order for a client to make use of the PUBREF operations they’ll need access to a database that look up public-keys and resolve their PUBREF index. A value can be resolved to an index with a hash-table lookup in O(1) constant time. Additionally, all instances of PUSHDATA can be indexed as an ordered list, resolution of a PUBREF index to the intended value would be an O(1) array lookup. Although the data needed to build and resolve public references is already included with every full node, additional computational effort is needed to build and maintain these indices - a tradeoff which provides smaller transaction sizes and relieving the need to store repetitive data on the blockchain.
This is not only necessary at the creator of the transaction --- it is also necessary at every validator.
In particular, consider existing pruning nodes, which cannot refer to previous block data.
We would need to have another new database containing every `PUSHDATA` in existence.
And existing pruning nodes would need to restart from genesis, as this database would not exist yet.
Regards,
ZmnSCPxj