Ruben Somsen [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-24 📝 Original message:In Q = P + ...
📅 Original date posted:2022-02-24
📝 Original message:In Q = P + hash(P||commitment)G you cannot spend from Q without knowing
both the private key of P as well as the commitment (i.e. 32 bytes,
assuming the commitment itself is another hash). This is generally not a
problem for tapscript, as the scripts are deterministically generated (i.e.
backing up the policy once is sufficient), but what you are suggesting is
not deterministic. Hope that clarifies things.
On Thu, Feb 24, 2022 at 2:27 PM <vjudeu at gazeta.pl> wrote:
> > Also, tweaking an ECC point (this includes tapscript) in
> non-deterministic ways also makes it harder to recover from backup, because
> you can't recover the key without knowing the full commitment.
>
> I don't think so. You can spend coins from taproot by key or by script. If
> you spend by key, making backup is simple, we have WIF for that. If you
> spend by script, you only need a part of the tree. So, you can "recover the
> key without knowing the full commitment", because you can spend coins
> "without knowing the full commitment". On-chain, you never reveal your
> "OP_RETURN <data>" or "OP_RETURN <hash>" or "<tapbranch> <tapbranch>
> <tapbranch> OP_RETURN <chunk_of_data>". Those additional branches are
> stored only by those who wants their data to be connected with some key,
> knowing the full script is not needed, because it is not needed for
> on-chain validation.
>
> > Furthermore, the scheme is not actually equivalent to op_return, because
> it requires the user to communicate out-of-band to reveal the commitment,
> whereas with op_return the data is immediately visible (while not popular,
> BIP47 and various colored coin protocols rely on this).
>
> Yes, but storing that additional data on-chain is not needed. It is
> expensive. By paying one satoshi per byte, you would pay 0.01 BTC for
> pushing 1 MB of data. That means 1 BTC for 100 MB of data, so 15 BTC for
> that 1.5 GB file. And in practice it is the absolute minimum, because you
> have to wrap your data somehow, you cannot just push 1.5 GB file. By
> placing that in TapScript, you can use your taproot public key as usual and
> attach any data into your key for "free", because it takes zero additional
> bytes on-chain.
>
> On 2022-02-24 11:08:39 user Ruben Somsen <rsomsen at gmail.com> wrote:
>
> Note this has always been possible, and is not specifically related to
> tapscript. As long as you're committing to an ECC point, you can tweak it
> to commit data inside it (i.e. pay-to-contract). This includes P2PK and
> P2PKH.
>
> Committing to 1.5GB of data has equally been possible with OP_RETURN
> <hash>, or even an entire merkle tree of hashes, as is the case with Todd's
> opentimestamps.
>
> Also, tweaking an ECC point (this includes tapscript) in non-deterministic
> ways also makes it harder to recover from backup, because you can't recover
> the key without knowing the full commitment.
>
> Furthermore, the scheme is not actually equivalent to op_return, because
> it requires the user to communicate out-of-band to reveal the commitment,
> whereas with op_return the data is immediately visible (while not popular,
> BIP47 and various colored coin protocols rely on this).
>
> Cheers,
> Ruben
>
>
> On Thu, Feb 24, 2022 at 10:19 AM vjudeu via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org
> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8>>;
> 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.
>>
>> Currently in Bitcoin Core we have "data" field in "createrawtransaction".
>> Should the implementation be changed to place that data in a TapScript
>> instead of creating separate OP_RETURN output? What do you think?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8>;
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/598293c1/attachment.html>;
📝 Original message:In Q = P + hash(P||commitment)G you cannot spend from Q without knowing
both the private key of P as well as the commitment (i.e. 32 bytes,
assuming the commitment itself is another hash). This is generally not a
problem for tapscript, as the scripts are deterministically generated (i.e.
backing up the policy once is sufficient), but what you are suggesting is
not deterministic. Hope that clarifies things.
On Thu, Feb 24, 2022 at 2:27 PM <vjudeu at gazeta.pl> wrote:
> > Also, tweaking an ECC point (this includes tapscript) in
> non-deterministic ways also makes it harder to recover from backup, because
> you can't recover the key without knowing the full commitment.
>
> I don't think so. You can spend coins from taproot by key or by script. If
> you spend by key, making backup is simple, we have WIF for that. If you
> spend by script, you only need a part of the tree. So, you can "recover the
> key without knowing the full commitment", because you can spend coins
> "without knowing the full commitment". On-chain, you never reveal your
> "OP_RETURN <data>" or "OP_RETURN <hash>" or "<tapbranch> <tapbranch>
> <tapbranch> OP_RETURN <chunk_of_data>". Those additional branches are
> stored only by those who wants their data to be connected with some key,
> knowing the full script is not needed, because it is not needed for
> on-chain validation.
>
> > Furthermore, the scheme is not actually equivalent to op_return, because
> it requires the user to communicate out-of-band to reveal the commitment,
> whereas with op_return the data is immediately visible (while not popular,
> BIP47 and various colored coin protocols rely on this).
>
> Yes, but storing that additional data on-chain is not needed. It is
> expensive. By paying one satoshi per byte, you would pay 0.01 BTC for
> pushing 1 MB of data. That means 1 BTC for 100 MB of data, so 15 BTC for
> that 1.5 GB file. And in practice it is the absolute minimum, because you
> have to wrap your data somehow, you cannot just push 1.5 GB file. By
> placing that in TapScript, you can use your taproot public key as usual and
> attach any data into your key for "free", because it takes zero additional
> bytes on-chain.
>
> On 2022-02-24 11:08:39 user Ruben Somsen <rsomsen at gmail.com> wrote:
>
> Note this has always been possible, and is not specifically related to
> tapscript. As long as you're committing to an ECC point, you can tweak it
> to commit data inside it (i.e. pay-to-contract). This includes P2PK and
> P2PKH.
>
> Committing to 1.5GB of data has equally been possible with OP_RETURN
> <hash>, or even an entire merkle tree of hashes, as is the case with Todd's
> opentimestamps.
>
> Also, tweaking an ECC point (this includes tapscript) in non-deterministic
> ways also makes it harder to recover from backup, because you can't recover
> the key without knowing the full commitment.
>
> Furthermore, the scheme is not actually equivalent to op_return, because
> it requires the user to communicate out-of-band to reveal the commitment,
> whereas with op_return the data is immediately visible (while not popular,
> BIP47 and various colored coin protocols rely on this).
>
> Cheers,
> Ruben
>
>
> On Thu, Feb 24, 2022 at 10:19 AM vjudeu via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org
> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8>>;
> 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.
>>
>> Currently in Bitcoin Core we have "data" field in "createrawtransaction".
>> Should the implementation be changed to place that data in a TapScript
>> instead of creating separate OP_RETURN output? What do you think?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8>;
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/598293c1/attachment.html>;