Kostas Karasavvas [ARCHIVE] on Nostr: 📅 Original date posted:2022-03-21 📝 Original message:Hi vjudeu, There are use ...
📅 Original date posted:2022-03-21
📝 Original message:Hi vjudeu,
There are use cases where your following assumption is wrong: ".. and that
kind of data is useful only to the transaction maker."
No one really publishes the actual data with an OP_RETURN. They publish the
hash (typically merkle root) of that 1.5 GB of data. So the overhead is
just 32 bytes for arbitrarily large data sets. What you gain with these 32
bytes is that your hash is visible to anyone and they can verify it without
active participation of the hash publisher.
Regards,
Kostas
On Sat, Mar 19, 2022 at 9:26 PM vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > There are two use-cases for OP_RETURN: committing to data, and
> publishing data. Your proposal can only do the former, not the latter, and
> there are use-cases for both.
>
> Only the former is needed. Pushing data on-chain is expensive and that
> kind of data is useful only to the transaction maker. Also, the latter can
> be pushed on a separate chain (or even a separate layer that is not a chain
> at all).
>
> Also note that since Taproot we have the latter: we can spend by TapScript
> and reveal some public key and tapbranches. It is possible to push more
> than 80 bytes in this way, so why direct OP_RETURN is needed, except for
> backward-compatibility? (for example in Segwit commitments)
>
> There is only one problem with spending by TapScript, when it comes to
> publishing data: only the first item is the public key. If we could use
> public keys instead of tapbranch hashes, we could literally replace
> "OP_RETURN <commitment>" with "<tweakedPublicKey> <tweakedTapBranchKey1>
> <tweakedTapBranchKey2> <tweakedTapBranchKey3> ... <tweakedTapBranchKeyN>".
> Then, we could use unspendable public keys to push data, so OP_RETURN would
> be obsolete.
>
> By the way, committing to data has a lot of use cases, for example the
> whole idea of NameCoin could be implemented on such OP_RETURN's. Instead of
> creating some special transaction upfront, people could place some hidden
> commitment and reveal that later. Then, there would be no need to produce
> any new coins out of thin air, because everything would be merge-mined by
> default, providing Bitcoin-level Proof of Work protection all the time,
> 24/7/365. Then, people could store that revealed commitments on their own
> chain, just to keep track of who owns which name. And then, that network
> could easily turn on and off all Bitcoin features as they please. Lightning
> Network on NameCoin? No problem, even the same satoshis could be used to
> pay for domains!
>
> On 2022-03-16 19:21:37 user Peter Todd <pete at petertodd.org> wrote:
> > On Thu, Feb 24, 2022 at 10:02:08AM +0100, vjudeu via bitcoin-dev wrote:
> > Since Taproot was activated, we no longer need separate OP_RETURN
> outputs to be pushed on-chain. If we want to attach any data to a
> transaction, we can create "OP_RETURN <anything>" as a branch in the
> TapScript. In this way, we can store that data off-chain and we can always
> prove that they are connected with some taproot address, that was pushed
> on-chain. Also, we can store more than 80 bytes for "free", because no such
> taproot branch will be ever pushed on-chain and used as an input. That
> means we can use "OP_RETURN <1.5 GB of data>", create some address having
> that taproot branch, and later prove to anyone that such "1.5 GB of data"
> is connected with our taproot address.
>
> There are two use-cases for OP_RETURN: committing to data, and publishing
> data.
> Your proposal can only do the former, not the latter, and there are
> use-cases
> for both.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> 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/20220321/73bed610/attachment-0001.html>;
📝 Original message:Hi vjudeu,
There are use cases where your following assumption is wrong: ".. and that
kind of data is useful only to the transaction maker."
No one really publishes the actual data with an OP_RETURN. They publish the
hash (typically merkle root) of that 1.5 GB of data. So the overhead is
just 32 bytes for arbitrarily large data sets. What you gain with these 32
bytes is that your hash is visible to anyone and they can verify it without
active participation of the hash publisher.
Regards,
Kostas
On Sat, Mar 19, 2022 at 9:26 PM vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > There are two use-cases for OP_RETURN: committing to data, and
> publishing data. Your proposal can only do the former, not the latter, and
> there are use-cases for both.
>
> Only the former is needed. Pushing data on-chain is expensive and that
> kind of data is useful only to the transaction maker. Also, the latter can
> be pushed on a separate chain (or even a separate layer that is not a chain
> at all).
>
> Also note that since Taproot we have the latter: we can spend by TapScript
> and reveal some public key and tapbranches. It is possible to push more
> than 80 bytes in this way, so why direct OP_RETURN is needed, except for
> backward-compatibility? (for example in Segwit commitments)
>
> There is only one problem with spending by TapScript, when it comes to
> publishing data: only the first item is the public key. If we could use
> public keys instead of tapbranch hashes, we could literally replace
> "OP_RETURN <commitment>" with "<tweakedPublicKey> <tweakedTapBranchKey1>
> <tweakedTapBranchKey2> <tweakedTapBranchKey3> ... <tweakedTapBranchKeyN>".
> Then, we could use unspendable public keys to push data, so OP_RETURN would
> be obsolete.
>
> By the way, committing to data has a lot of use cases, for example the
> whole idea of NameCoin could be implemented on such OP_RETURN's. Instead of
> creating some special transaction upfront, people could place some hidden
> commitment and reveal that later. Then, there would be no need to produce
> any new coins out of thin air, because everything would be merge-mined by
> default, providing Bitcoin-level Proof of Work protection all the time,
> 24/7/365. Then, people could store that revealed commitments on their own
> chain, just to keep track of who owns which name. And then, that network
> could easily turn on and off all Bitcoin features as they please. Lightning
> Network on NameCoin? No problem, even the same satoshis could be used to
> pay for domains!
>
> On 2022-03-16 19:21:37 user Peter Todd <pete at petertodd.org> wrote:
> > On Thu, Feb 24, 2022 at 10:02:08AM +0100, vjudeu via bitcoin-dev wrote:
> > Since Taproot was activated, we no longer need separate OP_RETURN
> outputs to be pushed on-chain. If we want to attach any data to a
> transaction, we can create "OP_RETURN <anything>" as a branch in the
> TapScript. In this way, we can store that data off-chain and we can always
> prove that they are connected with some taproot address, that was pushed
> on-chain. Also, we can store more than 80 bytes for "free", because no such
> taproot branch will be ever pushed on-chain and used as an input. That
> means we can use "OP_RETURN <1.5 GB of data>", create some address having
> that taproot branch, and later prove to anyone that such "1.5 GB of data"
> is connected with our taproot address.
>
> There are two use-cases for OP_RETURN: committing to data, and publishing
> data.
> Your proposal can only do the former, not the latter, and there are
> use-cases
> for both.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> 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/20220321/73bed610/attachment-0001.html>;