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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to