[bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

All other things being equal, which is better if you need to place a
64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
taproot transaction such as:

OP_FALSE
OP_IF
OP_PUSH my64bytes
OP_ENDIF

I know that the anti-OP_RETURN folk would say “neither.” But if there was
no other choice for a particular protocol, such as a timestamp or a
commitment, which is better? Or is there a safer place to put 64 bytes that
is more uncensorable but also does not clog UTXO space, only spent
transaction `-txindex` space?

My best guess was that the taproot method is better, but I suspect there
might be some who disagree. I'd love to hear all sides.

-- Christopher Allen

[-- Attachment #2: Type: text/html, Size: 843 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Peter Todd]

On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>All other things being equal, which is better if you need to place a
>64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
>taproot transaction such as:
>
>OP_FALSE
>OP_IF
>OP_PUSH my64bytes
>OP_ENDIF

What's wrong with OpPush <data> OpDrop?

>I know that the anti-OP_RETURN folk would say “neither.” But if there was
>no other choice for a particular protocol, such as a timestamp or a
>commitment, which is better? Or is there a safer place to put 64 bytes that
>is more uncensorable but also does not clog UTXO space, only spent
>transaction `-txindex` space?
>
>My best guess was that the taproot method is better, but I suspect there
>might be some who disagree. I'd love to hear all sides.

An important consideration with using taproot is that you need to have the data you are committing too to be able to to spend the txout in the future. OpReturn doesn't have that problem, meaning that in a situation like a hard drive failure, you can still recover the funds from a wallet seed.

Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The whole point of OpReturn is to standardize a way to keep such outputs out of the UTXO set. There is the 75% discount to using witness space. But considering the size of a transaction as a whole using taproot instead of OpReturn doesn't save much.

Finally, _64_ bytes is more than a mere 32 byte commitment. What specific use case do you actually have in mind here? Are you actually publishing data, or simply committing to data? If the latter, you can use ECC commitments and have no extra space at all.

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

I don't have a concrete proposal in mind, I'm just trying to understand
various tradeoffs in post-taproot bitcoin in more detail.

On Tue, Jan 31, 2023 at 6:07 PM Peter Todd <pete@petertodd.org> wrote:

>
> >OP_FALSE
> >OP_IF
> >OP_PUSH my64bytes
> >OP_ENDIF
>
> What's wrong with OpPush <data> OpDrop?
>

I'm not sure pro or con of either. I just saw that proposal above recently.


> Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The
> whole point of OpReturn is to standardize a way to keep such outputs out of
> the UTXO set. There is the 75% discount to using witness space. But
> considering the size of a transaction as a whole using taproot instead of
> OpReturn doesn't save much.
>

There are OP_RETURN tricks in production that do clog UTXO space. I was
trying to avoid consideration of those by just saying to compare apples vs.
apples, by presuming that any form of these transactions holding the 64
bytes is a spent transaction.

Finally, _64_ bytes is more than a mere 32 byte commitment. What specific
> use case do you actually have in mind here? Are you actually publishing
> data, or simply committing to data? If the latter, you can use ECC
> commitments and have no extra space at all.
>

I chose 64 bytes for this exercise, as I know there are tricks hiding 32
bytes as keys. As almost every op_return live out there is >32 bytes, I
wanted an example that could be a signature, two hashes, a hash plus some
metadata, etc. I also considered 96 bytes (for instance a hash and a
signature), but as that doesn't fit into OP_RETURN's 80 bytes, that choice
prohibits comparing the different approaches side-by-side.

To come back to my question another way, if you ignore the people who say
"never put anything except data facilitating coin transactions into the
bitcoin blockchain", but if you also are not trying to use the bitcoin
blockchain as a world database (ala ETH), what is the most pragmatic way to
do so that minimizes any potential harm? The answer pre-taproot was
OP_RETURN. What is it now?

-- Christopher Allen

[-- Attachment #2: Type: text/html, Size: 2980 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Kostas Karasavvas]

[-- Attachment #1: Type: text/plain, Size: 2920 bytes --]

With OP_RETURN you publish some data that are immediately visible in the
blockchain. I would consider this better (more straightforward) for things
like time-stamping.

With Taproot you need to spend the utxo to make the script visible. This
seems better when you don't want the data public but you need to be able to
reveal the data when the time comes.

Unless it is important to reveal later, it seems to me that for 80 bytes or
less OP_RETURN is still the way to go post-taproot.



On Wed, 1 Feb 2023, 04:30 Christopher Allen via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't have a concrete proposal in mind, I'm just trying to understand
> various tradeoffs in post-taproot bitcoin in more detail.
>
> On Tue, Jan 31, 2023 at 6:07 PM Peter Todd <pete@petertodd.org> wrote:
>
>>
>> >OP_FALSE
>> >OP_IF
>> >OP_PUSH my64bytes
>> >OP_ENDIF
>>
>> What's wrong with OpPush <data> OpDrop?
>>
>
> I'm not sure pro or con of either. I just saw that proposal above recently.
>
>
>> Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The
>> whole point of OpReturn is to standardize a way to keep such outputs out of
>> the UTXO set. There is the 75% discount to using witness space. But
>> considering the size of a transaction as a whole using taproot instead of
>> OpReturn doesn't save much.
>>
>
> There are OP_RETURN tricks in production that do clog UTXO space. I was
> trying to avoid consideration of those by just saying to compare apples vs.
> apples, by presuming that any form of these transactions holding the 64
> bytes is a spent transaction.
>
> Finally, _64_ bytes is more than a mere 32 byte commitment. What specific
>> use case do you actually have in mind here? Are you actually publishing
>> data, or simply committing to data? If the latter, you can use ECC
>> commitments and have no extra space at all.
>>
>
> I chose 64 bytes for this exercise, as I know there are tricks hiding 32
> bytes as keys. As almost every op_return live out there is >32 bytes, I
> wanted an example that could be a signature, two hashes, a hash plus some
> metadata, etc. I also considered 96 bytes (for instance a hash and a
> signature), but as that doesn't fit into OP_RETURN's 80 bytes, that choice
> prohibits comparing the different approaches side-by-side.
>
> To come back to my question another way, if you ignore the people who say
> "never put anything except data facilitating coin transactions into the
> bitcoin blockchain", but if you also are not trying to use the bitcoin
> blockchain as a world database (ala ETH), what is the most pragmatic way to
> do so that minimizes any potential harm? The answer pre-taproot was
> OP_RETURN. What is it now?
>
> -- Christopher Allen
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4430 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Peter Todd]

On February 1, 2023 8:36:52 AM GMT, Kostas Karasavvas <kkarasavvas@gmail.com> wrote:
>With OP_RETURN you publish some data that are immediately visible in the
>blockchain. I would consider this better (more straightforward) for things
>like time-stamping.

You are incorrect. Time-stamps merely prove that data existed prior to some point in time. There is absolutely no need for anything to be published in the blockchain to create a timestamp. Indeed, efficient timestamps don't actually publish any meaningful data: for efficiency you always combine many timestamps into a single merkle tree; a merkle tree tip digest is meaningless data by itself.

OpenTimestamps does in fact use OpReturn rather than something more efficient. But it does this only because the efficiency gain isn't significant enough for me to have gotten around to improving it. Reducing fee costs by ~10% isn't a good use of my time.

>With Taproot you need to spend the utxo to make the script visible. This
>seems better when you don't want the data public but you need to be able to
>reveal the data when the time comes.

If your concern is the data being public due to OpReturn vs Taproot, you are confused and need to think more carefully about what exactly you are doing.

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:
> 
> 
> On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >All other things being equal, which is better if you need to place a
> >64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
> >taproot transaction such as:
> >
> >OP_FALSE
> >OP_IF
> >OP_PUSH my64bytes
> >OP_ENDIF
> 
> What's wrong with OpPush <data> OpDrop?
>

This is a technical nit, but the reason is that <data> is limited to 520
bytes (and I believe, 80 bytes by standardness in Taproot), so if you
are pushing a ton of data and need multiple pushes, it's more efficient
to use FALSE IF ... ENDIF since you avoid the repeated DROPs.

-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

On Wed, Feb 01, 2023 at 02:02:41PM +0000, Andrew Poelstra wrote:
> On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:
> > 
> > 
> > On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >All other things being equal, which is better if you need to place a
> > >64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
> > >taproot transaction such as:
> > >
> > >OP_FALSE
> > >OP_IF
> > >OP_PUSH my64bytes
> > >OP_ENDIF
> > 
> > What's wrong with OpPush <data> OpDrop?
> >
> 
> This is a technical nit, but the reason is that <data> is limited to 520
> bytes (and I believe, 80 bytes by standardness in Taproot), so if you
> are pushing a ton of data and need multiple pushes, it's more efficient
> to use FALSE IF ... ENDIF since you avoid the repeated DROPs.

Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's
not executed. But in this example we're just talking about 64 bytes, so that
limit isn't relevant and OpPush <data> OpDrop should be sufficient.

Specifically for more than 520 bytes you run into the the
MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all
scripts regardless of standardness at script execution:

           //
           // Read instruction
           //
           if (!script.GetOp(pc, opcode, vchPushValue))
               return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
           if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE)
               return set_error(serror, SCRIPT_ERR_PUSH_SIZE);

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

As far as I can read nobody replied to the initial question: what is
considered as good/best practice to store in Bitcoin?

Reiterating my question: what are the current rules for OP_RETURN, max
size and number of OP_RETURN per tx


Le 02/02/2023 à 12:22, Peter Todd via bitcoin-dev a écrit :
> On Wed, Feb 01, 2023 at 02:02:41PM +0000, Andrew Poelstra wrote:
>> On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:
>>>
>>> On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> All other things being equal, which is better if you need to place a
>>>> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
>>>> taproot transaction such as:
>>>>
>>>> OP_FALSE
>>>> OP_IF
>>>> OP_PUSH my64bytes
>>>> OP_ENDIF
>>> What's wrong with OpPush <data> OpDrop?
>>>
>> This is a technical nit, but the reason is that <data> is limited to 520
>> bytes (and I believe, 80 bytes by standardness in Taproot), so if you
>> are pushing a ton of data and need multiple pushes, it's more efficient
>> to use FALSE IF ... ENDIF since you avoid the repeated DROPs.
> Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's
> not executed. But in this example we're just talking about 64 bytes, so that
> limit isn't relevant and OpPush <data> OpDrop should be sufficient.
>
> Specifically for more than 520 bytes you run into the the
> MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all
> scripts regardless of standardness at script execution:
>
>            //
>            // Read instruction
>            //
>            if (!script.GetOp(pc, opcode, vchPushValue))
>                return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
>            if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE)
>                return set_error(serror, SCRIPT_ERR_PUSH_SIZE);
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com


[-- Attachment #2: Type: text/html, Size: 4824 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Thu, Feb 02, 2023 at 12:45:42PM +0100, Aymeric Vitte wrote:
> As far as I can read nobody replied to the initial question: what is
> considered as good/best practice to store in Bitcoin?

Your answer is beyond not putting unspendable data in the UTXO set, the exact
details don't really matter. Do what makes sense for your specific application.

> Reiterating my question: what are the current rules for OP_RETURN, max
> size and number of OP_RETURN per tx

Max 80 bytes, one OpReturn output per tx.

This of course is the standardness rule. With a miner willing to mine non-std
transactions anything goes.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

Thanks, then this limitation should be rethought I think (see the email
I just sent replying to the coloured thread)

Because it forces people to store in witness (less easy to track/show I
believe) or adopt some deviant behavior (like storing in addresses where
the utxo will remain unspendable forever)


Le 02/02/2023 à 12:49, Peter Todd a écrit :
> On Thu, Feb 02, 2023 at 12:45:42PM +0100, Aymeric Vitte wrote:
>> As far as I can read nobody replied to the initial question: what is
>> considered as good/best practice to store in Bitcoin?
> Your answer is beyond not putting unspendable data in the UTXO set, the exact
> details don't really matter. Do what makes sense for your specific application.
>
>> Reiterating my question: what are the current rules for OP_RETURN, max
>> size and number of OP_RETURN per tx
> Max 80 bytes, one OpReturn output per tx.
>
> This of course is the standardness rule. With a miner willing to mine non-std
> transactions anything goes.
>

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 2677 bytes --]

Could someone clarify what is the standard for OP_RETURN? As far as I
understand the data is limited to 80B and only one OP_RETURN is allowed
in one transaction, if not the tx is non standard, correct?

Then the debate can be to store in witness indeed

Or you can store in output addresses (with super big size), then you
will never be able to spend the dust and we have a utxo forever

In any case there is a storage workaround, probably others exist, not
sure why people are so opposed to a OP_RETURN bitcoin storage (I thought
the max size was 512B, but apparently I am wrong, 80B is ridiculous,
can't do anything with this, except bypassing this limit by other worse
means)

Storage is the main difference between bitcoin and other systems
(ethereum), without it, repeating myself here again the future of
bitcoin is very limited

PS: I saw the answer of Peter, I am proposing something else for
timestamp proofs

Le 01/02/2023 à 01:46, Christopher Allen via bitcoin-dev a écrit :
> All other things being equal, which is better if you need to place a
> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a
> spent taproot transaction such as:
>
> OP_FALSE
> OP_IF 
> OP_PUSH my64bytes
> OP_ENDIF
>
> I know that the anti-OP_RETURN folk would say “neither.” But if there
> was no other choice for a particular protocol, such as a timestamp or
> a commitment, which is better? Or is there a safer place to put 64
> bytes that is more uncensorable but also does not clog UTXO space,
> only spent transaction `-txindex` space?
>
> My best guess was that the taproot method is better, but I suspect
> there might be some who disagree. I'd love to hear all sides.
>
> -- Christopher Allen
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com


[-- Attachment #2: Type: text/html, Size: 4851 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Rijndael]

Hello Christopher,

I think if the protocol that you were designing always had <80 bytes,
I'd prefer the OP_RETURN. I think the "witness envelope" has two major
disadvantages compared to the OP_RETURN method:

1. You need to first spend to he address that commits to the script that
encodes your data payload. So you have a two step process of first
spending to a "commitment" address and then a second spend to "reveal"
your payload. You can CPFP to get them both into the same block, but its
still two transactions, so more cost, etc.

2. Because of the two step process in (1), if for some reason you were
unable to get the "reveal" transaction into a block (for example there's
widespread censorship of transactions that match the format of the
"reveal" script), then you might have money that's stuck in the "commit"
stage of the protocol. The way out of this would be to get your money
out via the keypath or another tapleaf, but then you need to spend money
to cancel a step in your protocol. Of course there could be widespread
censorship of your OP_RETURNs too, but you don't have to spend funds on
the cancellation spends.

I think (2) is actually a pretty weak argument because as we saw in the
full-rbf discussion, as long as there's some threshold number of nodes
in the network that relay transactions to miners, you can probably find
a path to a miner (IIRC the number was on the order of 15% of the
network?). So I think the big reason to pick OP_RETURN over the witness
embedding is that you save a transaction and possibly some
failure-recovery/cancellation logic.

Obviously if your data is larger than 80 bytes, then you probably want
to do the witness-embedding method. If your data smaller, then a
pay-to-contract tweak probably the best thing from a space and
fingerprinting perspective.

- rijndael


On 1/31/23 7:46 PM, Christopher Allen via bitcoin-dev wrote:
> All other things being equal, which is better if you need to place a
> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a
> spent taproot transaction such as:
>
> OP_FALSE
> OP_IF
> OP_PUSH my64bytes
> OP_ENDIF
>
> I know that the anti-OP_RETURN folk would say “neither.” But if there
> was no other choice for a particular protocol, such as a timestamp or
> a commitment, which is better? Or is there a safer place to put 64
> bytes that is more uncensorable but also does not clog UTXO space,
> only spent transaction `-txindex` space?
>
> My best guess was that the taproot method is better, but I suspect
> there might be some who disagree. I'd love to hear all sides.
>
> -- Christopher Allen
>

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

Indeed the witness envelope is more costly and less easy to use (or
read/track)

But let's take a standard P2PKH or P2WPKH output,  what prevents me from
adding in the beginning of scriptSig or witness while spending it:
OP_PUSH <data> OP_DROP ? Non standard ? This one makes one transaction only

There are probably plenty of ways to store data, another one would be to
use a dummy 1 of N multisig where only 1 corresponds to a pubkey and the
rest is data, but again several transactions...

I think the right way so people don't invent deviant things is to
increase the size of OP_RETURN, I don't get this number of 80B, you can
hardly store a signature (of what?) in there and not the "what" if the
"what" is a hash for example


Le 02/02/2023 à 14:25, Rijndael via bitcoin-dev a écrit :
> Hello Christopher,
>
> I think if the protocol that you were designing always had <80 bytes,
> I'd prefer the OP_RETURN. I think the "witness envelope" has two major
> disadvantages compared to the OP_RETURN method:
>
> 1. You need to first spend to he address that commits to the script that
> encodes your data payload. So you have a two step process of first
> spending to a "commitment" address and then a second spend to "reveal"
> your payload. You can CPFP to get them both into the same block, but its
> still two transactions, so more cost, etc.
>
> 2. Because of the two step process in (1), if for some reason you were
> unable to get the "reveal" transaction into a block (for example there's
> widespread censorship of transactions that match the format of the
> "reveal" script), then you might have money that's stuck in the "commit"
> stage of the protocol. The way out of this would be to get your money
> out via the keypath or another tapleaf, but then you need to spend money
> to cancel a step in your protocol. Of course there could be widespread
> censorship of your OP_RETURNs too, but you don't have to spend funds on
> the cancellation spends.
>
> I think (2) is actually a pretty weak argument because as we saw in the
> full-rbf discussion, as long as there's some threshold number of nodes
> in the network that relay transactions to miners, you can probably find
> a path to a miner (IIRC the number was on the order of 15% of the
> network?). So I think the big reason to pick OP_RETURN over the witness
> embedding is that you save a transaction and possibly some
> failure-recovery/cancellation logic.
>
> Obviously if your data is larger than 80 bytes, then you probably want
> to do the witness-embedding method. If your data smaller, then a
> pay-to-contract tweak probably the best thing from a space and
> fingerprinting perspective.
>
> - rijndael
>
>
> On 1/31/23 7:46 PM, Christopher Allen via bitcoin-dev wrote:
>> All other things being equal, which is better if you need to place a
>> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a
>> spent taproot transaction such as:
>>
>> OP_FALSE
>> OP_IF
>> OP_PUSH my64bytes
>> OP_ENDIF
>>
>> I know that the anti-OP_RETURN folk would say “neither.” But if there
>> was no other choice for a particular protocol, such as a timestamp or
>> a commitment, which is better? Or is there a safer place to put 64
>> bytes that is more uncensorable but also does not clog UTXO space,
>> only spent transaction `-txindex` space?
>>
>> My best guess was that the taproot method is better, but I suspect
>> there might be some who disagree. I'd love to hear all sides.
>>
>> -- Christopher Allen
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I think the right way so people don't invent deviant things is to
> increase the size of OP_RETURN, I don't get this number of 80B, you can
> hardly store a signature (of what?) in there and not the "what" if the
> "what" is a hash for example
>

Updating the size of OP_RETURN to support a hash (or two), a signature, and
maybe a few more bytes for metadata, would be very helpful in a number of
scenarios. It is still a limit but a reasonable one. Otherwise, I think
we'll have a lot more inscription-style scenarios.

-- Christopher Allen

[-- Attachment #2: Type: text/html, Size: 1059 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Kostas Karasavvas]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I think the right way so people don't invent deviant things is to
>> increase the size of OP_RETURN, I don't get this number of 80B, you can
>> hardly store a signature (of what?) in there and not the "what" if the
>> "what" is a hash for example
>>
>
> Updating the size of OP_RETURN to support a hash (or two), a signature,
> and maybe a few more bytes for metadata, would be very helpful in a number
> of scenarios. It is still a limit but a reasonable one. Otherwise, I think
> we'll have a lot more inscription-style scenarios.
>

I wouldn't be against an increase in OP_RETURN but I don't think it will
make any difference in how often inscription-style use cases will be used.
They will be used primarily for much larger datasets than, say 120 bytes,
and they also have the segwit discount.

[-- Attachment #2: Type: text/html, Size: 1722 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 3231 bytes --]

I don't get very well where all the current (other threats) discussions
are going, storing on-chain is absurd

It's absurd also to flood bitcoin with several useless transactions to
store in witness or others, looks like ethereum messy stuff

What is not absurd is to store the proofs that can be checked using a
notorious third party/sidechain but you need more than 80B

What is the official bitcoin channel to request the OP_RETURN size
change? (press often mentions that ethereum is good to manage changes
and bitcoin a complete zero)

As a very bad solution, I think I would be willing to store data in
addresses, with one single transaction, as people did in the past, then
burning bitcoins but still not expensive, or less than several txs,
because schemes involving several transactions do not work very well

In any case, we see the problem, then people will invent something and
most likely it will not comply at all with bitcoin good practices


Le 04/02/2023 à 15:11, Kostas Karasavvas via bitcoin-dev a écrit :
>
>
> On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev
>     <bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>         I think the right way so people don't invent deviant things is to
>         increase the size of OP_RETURN, I don't get this number of
>         80B, you can
>         hardly store a signature (of what?) in there and not the
>         "what" if the
>         "what" is a hash for example
>
>
>     Updating the size of OP_RETURN to support a hash (or two), a
>     signature, and maybe a few more bytes for metadata, would be very
>     helpful in a number of scenarios. It is still a limit but a
>     reasonable one. Otherwise, I think we'll have a lot more
>     inscription-style scenarios.
>
>
> I wouldn't be against an increase in OP_RETURN but I don't think it
> will make any difference in how often inscription-style use cases will
> be used. They will be used primarily for much larger datasets than,
> say 120 bytes, and they also have the segwit discount.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com


[-- Attachment #2: Type: text/html, Size: 6243 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte <aymeric@peersm.com> wrote:

> What is the official bitcoin channel to request the OP_RETURN size change?
> (press often mentions that ethereum is good to manage changes and bitcoin a
> complete zero.
>
Here is the simplified version:

Most of these changes start with discussions like these, but then are moved
concretely to a PR to bitcoin-core with the code changes (in this case
there is no fork so pretty easy) and an introductory comment pointing to
discussions elsewhere.

The conversation will also move to the PR itself. Part of the challenge now
is getting review of your PRs - you’ll need to evangelize some and/or have
social capital in the bitcoin community to get sufficient ACKs to your PR
(and some NACKs which you will calmly addres), and someone will likely
point something out you missed, so you revise the PR.

At some point hopefully there looks like all reasonable objections have
been addressed.

If there is enough interest and few objections there will be discussions by
the community & maintainers to merge it. It is this last part that isn’t
very transparent, especially for even a good proposal. The maintainers,
based on their sense of the community’s interest and consensus, must choose
when to say it is ready, and then decide when and to which release they
wish to merge it.

They often start by requesting you to revise your changes to be off by
default, and be turned on as an option for a specific release. Often PR
contributors know this is coming and include it.

Even once it is released, this type of change can only happen after
sufficient miners and nodes update to the release and turn it on. If
sufficient do, then the maintainers evaluate when to have the feature on by
default.

These articles offers more perspective:

   -

   https://unchained.com/blog/contributing-bitcoin-core-patience/
   -


   https://jonatack.github.io/articles/how-to-contribute-pull-requests-to-bitcoin-core
   -

   https://medium.com/@amitiu/onboarding-to-bitcoin-core-7c1a83b20365

— Christopher Allen

>

[-- Attachment #2: Type: text/html, Size: 4524 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 4049 bytes --]

Thanks Christopher, then I understand the process:

- I must issue a PR where I switch 80 to another number, even if I am
not a C/C++ expert it looks easy

- I  must stay calm and answer all outstanding concerns about this
trivial change

- Since I am not as clever as the bitcoin devs I must be ready to revise
my PR at any time

- This could lead for the change to be from 80B to 82.xB where x comes
from a non understandable crypto formula

- I must evangelize the change worldwide

- Once accepted, I must collude (pay) with the nodes/miners so they
update at a subtile block height decided by the community

And then I must pray that the PR does not survive myself

Looks like a pretty straight forward process

I am on this list since quite some time, so, seriously, this change is
needed, or, as I said before, deviant behaviours will happen, because
the "witness trick" or others do not work at all, and are clearly
similar to ethereum messy stuff


Le 04/02/2023 à 19:54, Christopher Allen a écrit :
> On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte <aymeric@peersm.com
> <mailto:aymeric@peersm.com>> wrote:
>
>     What is the official bitcoin channel to request the OP_RETURN size
>     change? (press often mentions that ethereum is good to manage
>     changes and bitcoin a complete zero.
>
> Here is the simplified version:
>
> Most of these changes start with discussions like these, but then are
> moved concretely to a PR to bitcoin-core with the code changes (in
> this case there is no fork so pretty easy) and an introductory comment
> pointing to discussions elsewhere. 
>
> The conversation will also move to the PR itself. Part of the
> challenge now is getting review of your PRs - you’ll need to
> evangelize some and/or have social capital in the bitcoin community to
> get sufficient ACKs to your PR (and some NACKs which you will calmly
> addres), and someone will likely point something out you missed, so
> you revise the PR. 
>
> At some point hopefully there looks like all reasonable objections
> have been addressed.
>
> If there is enough interest and few objections there will be
> discussions by the community & maintainers to merge it. It is this
> last part that isn’t very transparent, especially for even a good
> proposal. The maintainers, based on their sense of the community’s
> interest and consensus, must choose when to say it is ready, and then
> decide when and to which release they wish to merge it.
>
> They often start by requesting you to revise your changes to be off by
> default, and be turned on as an option for a specific release. Often
> PR contributors know this is coming and include it.
>
> Even once it is released, this type of change can only happen after
> sufficient miners and nodes update to the release and turn it on. If
> sufficient do, then the maintainers evaluate when to have the feature
> on by default.
>
> These articles offers more perspective: 
>
>  *
>
>     https://unchained.com/blog/contributing-bitcoin-core-patience/
>
>  *
>
>     https://jonatack.github.io/articles/how-to-contribute-pull-requests-to-bitcoin-core
>
>  *
>
>     https://medium.com/@amitiu/onboarding-to-bitcoin-core-7c1a83b20365
>
> — Christopher Allen 
>
>

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com


[-- Attachment #2: Type: text/html, Size: 9278 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]

On Sat, Feb 4, 2023 at 12:55 PM Aymeric Vitte <aymeric@peersm.com> wrote:

> Thanks Christopher, then I understand the process:
>
> - I must issue a PR where I switch 80 to another number, even if I am not
> a C/C++ expert it looks easy
>
Yes, this would be an easy PR, at least to start. I suspect that
longer-term, you'd need to draft some assistance to make it turn on/off
from when the bitcoin daemon is initialized. But that could wait until the
conversation has progressed some.

The harder part will be writing the initial comment, where you should
carefully explain the rationale, link to some existing conversations, try
to point out in advance the obvious objections and rationale despite them,
and explain your particular choice of number — 520 because that is a
similar limit in taproot? Some multiple of hash+signature+metadata to
satisfy others (that still might not be satisfied by any choice).

> - I  must stay calm and answer all outstanding concerns about this trivial
> change
>
> - Since I am not as clever as the bitcoin devs I must be ready to revise
> my PR at any time
>
> - This could lead for the change to be from 80B to 82.xB where x comes
> from a non understandable crypto formula
>
> - I must evangelize the change worldwide
>
> - Once accepted, I must collude (pay) with the nodes/miners so they update
> at a subtile block height decided by the community
>
That is true for forks, but I don't think this is a fork. It might require
resolving some mempool issues (for instance for mining pools). But for it
to become non-optional, you'll need to demonstrate that miners and full
nodes have turned it on. Thus that is more a conversation than "collusion
(pay)".

> And then I must pray that the PR does not survive myself
>
> Looks like a pretty straight forward process.
>
I've seen worse. I co-authored TLS 1.0 (6 years) and DID 1.0 (5 years).

> I am on this list since quite some time, so, seriously, this change is
> needed, or, as I said before, deviant behaviours will happen, because the
> "witness trick" or others do not work at all, and are clearly similar to
> ethereum messy stuff
>
You have at least Concept ACK from me! ;-)

-- Christopher Allen

[-- Attachment #2: Type: text/html, Size: 3501 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

I don't know, what number would you advise? When I made the
bitcoin-transactions nodejs module some years ago the limit (from the
specs) was 512B

It's not a fork, super easy to do

And necessary because bitcoin on ground of I don't know what rule
allowing the IF/ENDIF "unlimited" storage just mimics ethereum for the
worse, and is again quite dubious to use


Le 04/02/2023 à 23:18, Christopher Allen a écrit :
> 520 because that is a similar limit in taproot? Some multiple of
> hash+signature+metadata to satisfy others (that still might not be
> satisfied by any choice).

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Peter Todd]

On February 5, 2023 12:09:02 AM GMT+01:00, Aymeric Vitte via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>I don't know, what number would you advise? When I made the
>bitcoin-transactions nodejs module some years ago the limit (from the
>specs) was 512B

1) Allowing only one OpReturn output causes problems trying to compose different uses of OpReturn. We should allow any number of OpReturn outputs.

2) There's no reason to put a size limit given all the other ways people can publish data, including with a 75% discount. Let the fee market deal with it.

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

I think logically:

- if you want to store something big and can afford several txs in your
design, then you use something like witness

- if you want to store small things like signatures, addresses hashes
and some metadata and your design does not make several txs easy, then
you use OP_RETURN

Then how can we move forward with several OP_RETURN and no size limit?

I can start posting a bug/enhancement proposal in bitcoin repo but can't
write the PR


Le 05/02/2023 à 01:04, Peter Todd a écrit :
>
> On February 5, 2023 12:09:02 AM GMT+01:00, Aymeric Vitte via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> I don't know, what number would you advise? When I made the
>> bitcoin-transactions nodejs module some years ago the limit (from the
>> specs) was 512B
> 1) Allowing only one OpReturn output causes problems trying to compose different uses of OpReturn. We should allow any number of OpReturn outputs.
>
> 2) There's no reason to put a size limit given all the other ways people can publish data, including with a 75% discount. Let the fee market deal with it.

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Peter Todd]

On February 5, 2023 12:40:38 PM GMT+01:00, Aymeric Vitte <aymeric@peersm.com> wrote:
>I think logically:
>
>- if you want to store something big and can afford several txs in your
>design, then you use something like witness
>
>- if you want to store small things like signatures, addresses hashes
>and some metadata and your design does not make several txs easy, then
>you use OP_RETURN
>
>Then how can we move forward with several OP_RETURN and no size limit?

Because what matters is the impact on other users. OpReturn isn't in UTXO space and doesn't even take advantage of the witness discount, so it clearly has minimal impact.

Since it has minimal impact, there's no reason to micromanage exactly how people use it. Let them decide for themselves with the fee market. This is exactly the same as how we didn't put artificial limits on Taproot.

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

Yes I agree, let people decide and since taproot has no limits then it
sould be the same for OP_RETURN

I posted https://github.com/bitcoin/bitcoin/issues/27043


Le 05/02/2023 à 13:06, Peter Todd a écrit :
>
> On February 5, 2023 12:40:38 PM GMT+01:00, Aymeric Vitte <aymeric@peersm.com> wrote:
>> I think logically:
>>
>> - if you want to store something big and can afford several txs in your
>> design, then you use something like witness
>>
>> - if you want to store small things like signatures, addresses hashes
>> and some metadata and your design does not make several txs easy, then
>> you use OP_RETURN
>>
>> Then how can we move forward with several OP_RETURN and no size limit?
> Because what matters is the impact on other users. OpReturn isn't in UTXO space and doesn't even take advantage of the witness discount, so it clearly has minimal impact.
>
> Since it has minimal impact, there's no reason to micromanage exactly how people use it. Let them decide for themselves with the fee market. This is exactly the same as how we didn't put artificial limits on Taproot.

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

Since bytes in the witness are cheaper than bytes in the script pubkey,
there is a crossover point in data size where it will simply be cheaper to
use witness data.  Where that crossover point is depends on the finer
details of the overhead of the two methods, but you could make some
reasonable assumptions.  Such a calculation could form the basis of a
reasonable OP_RETURN proposal.  I don't know if it would be persuasive, but
it would at least be coherent.

On Sat., Feb. 4, 2023, 18:17 Aymeric Vitte via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't know, what number would you advise? When I made the
> bitcoin-transactions nodejs module some years ago the limit (from the
> specs) was 512B
>
> It's not a fork, super easy to do
>
> And necessary because bitcoin on ground of I don't know what rule
> allowing the IF/ENDIF "unlimited" storage just mimics ethereum for the
> worse, and is again quite dubious to use
>
>
> Le 04/02/2023 à 23:18, Christopher Allen a écrit :
> > 520 because that is a similar limit in taproot? Some multiple of
> > hash+signature+metadata to satisfy others (that still might not be
> > satisfied by any choice).
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 1976 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Peter Todd]

On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>Since bytes in the witness are cheaper than bytes in the script pubkey,
>there is a crossover point in data size where it will simply be cheaper to
>use witness data.  Where that crossover point is depends on the finer
>details of the overhead of the two methods, but you could make some
>reasonable assumptions.  Such a calculation could form the basis of a
>reasonable OP_RETURN proposal.  I don't know if it would be persuasive, but
>it would at least be coherent.

I don't think it's worth the technical complexity trying to carefully argue a specific limit. Let users decide for themselves how they want to use OpReturn.

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

On Sat., Feb. 4, 2023, 21:01 Peter Todd, <pete@petertodd.org> wrote:

>
>
> On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >Since bytes in the witness are cheaper than bytes in the script pubkey,
> >there is a crossover point in data size where it will simply be cheaper to
> >use witness data.  Where that crossover point is depends on the finer
> >details of the overhead of the two methods, but you could make some
> >reasonable assumptions.  Such a calculation could form the basis of a
> >reasonable OP_RETURN proposal.  I don't know if it would be persuasive,
> but
> >it would at least be coherent.
>
> I don't think it's worth the technical complexity trying to carefully
> argue a specific limit. Let users decide for themselves how they want to
> use OpReturn.
>

Even better.

>

[-- Attachment #2: Type: text/html, Size: 1524 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]

https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403

"What is the process to have someone do the PR for this? Or I do it and
most likely it will be a very shxtty one since I am not a C/C++ expert,
then wasting the time of everybody

It's urgently required, I did consider OP_RETURN as a dart in the past
but changed my mind, it's adapted to the current evolutions, not
flooding bitcoin with 2 txs while only 1 is needed

If not the best 1 tx solution is super simple: store in addresses, and
super bad at the end because burning bitcoins, while still not expensive
if you don't need to store big things"


Le 05/02/2023 à 19:12, Russell O'Connor via bitcoin-dev a écrit :
>
>
> On Sat., Feb. 4, 2023, 21:01 Peter Todd, <pete@petertodd.org
> <mailto:pete@petertodd.org>> wrote:
>
>
>
>     On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via
>     bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>     >Since bytes in the witness are cheaper than bytes in the script
>     pubkey,
>     >there is a crossover point in data size where it will simply be
>     cheaper to
>     >use witness data.  Where that crossover point is depends on the finer
>     >details of the overhead of the two methods, but you could make some
>     >reasonable assumptions.  Such a calculation could form the basis of a
>     >reasonable OP_RETURN proposal.  I don't know if it would be
>     persuasive, but
>     >it would at least be coherent.
>
>     I don't think it's worth the technical complexity trying to
>     carefully argue a specific limit. Let users decide for themselves
>     how they want to use OpReturn.
>
>
> Even better.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com


[-- Attachment #2: Type: text/html, Size: 5690 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 4041 bytes --]

It's super unclear how long it could take for such a change to be adopted

Then the answer is simple, see:
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation

Outstandingly, very, mega, bad, but working, bringing bitcoin back 10
years ago

But why not? If bitcoin folks don't get that we need a 1tx storage
solution for the future, then let's bring back bitcoin into the past and
destroy coins

Le 12/02/2023 à 17:23, Aymeric Vitte a écrit :
>
> https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403
>
> "What is the process to have someone do the PR for this? Or I do it
> and most likely it will be a very shxtty one since I am not a C/C++
> expert, then wasting the time of everybody
>
> It's urgently required, I did consider OP_RETURN as a dart in the past
> but changed my mind, it's adapted to the current evolutions, not
> flooding bitcoin with 2 txs while only 1 is needed
>
> If not the best 1 tx solution is super simple: store in addresses, and
> super bad at the end because burning bitcoins, while still not
> expensive if you don't need to store big things"
>
>
> Le 05/02/2023 à 19:12, Russell O'Connor via bitcoin-dev a écrit :
>>
>>
>> On Sat., Feb. 4, 2023, 21:01 Peter Todd, <pete@petertodd.org
>> <mailto:pete@petertodd.org>> wrote:
>>
>>
>>
>>     On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via
>>     bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>     >Since bytes in the witness are cheaper than bytes in the script
>>     pubkey,
>>     >there is a crossover point in data size where it will simply be
>>     cheaper to
>>     >use witness data.  Where that crossover point is depends on the
>>     finer
>>     >details of the overhead of the two methods, but you could make some
>>     >reasonable assumptions.  Such a calculation could form the basis
>>     of a
>>     >reasonable OP_RETURN proposal.  I don't know if it would be
>>     persuasive, but
>>     >it would at least be coherent.
>>
>>     I don't think it's worth the technical complexity trying to
>>     carefully argue a specific limit. Let users decide for themselves
>>     how they want to use OpReturn.
>>
>>
>> Even better.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> -- 
> Sophia-Antipolis, France
> CV: https://www.peersm.com/CVAV.pdf
> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
> GitHub : https://www.github.com/Ayms
> A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
> A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
> Peersm : http://www.peersm.com

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com


[-- Attachment #2: Type: text/html, Size: 8840 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Claus Ehrenberg]

[-- Attachment #1: Type: text/plain, Size: 4596 bytes --]

I propose to require all data to be in the op_return output PLUS add a
required op_return_hash field, which is checked by consensus. So that node
can re-validate the chain without having to store/download/look at the
contents of op_return data. The benefit of that little redundancy is that
"content-sensitive" communities can ignore the date they don't like.

Cheers
Claus

On Thu, Feb 16, 2023 at 7:30 PM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It's super unclear how long it could take for such a change to be adopted
>
> Then the answer is simple, see:
> https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation
>
> Outstandingly, very, mega, bad, but working, bringing bitcoin back 10
> years ago
>
> But why not? If bitcoin folks don't get that we need a 1tx storage
> solution for the future, then let's bring back bitcoin into the past and
> destroy coins
> Le 12/02/2023 à 17:23, Aymeric Vitte a écrit :
>
> https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403
>
> "What is the process to have someone do the PR for this? Or I do it and
> most likely it will be a very shxtty one since I am not a C/C++ expert,
> then wasting the time of everybody
>
> It's urgently required, I did consider OP_RETURN as a dart in the past but
> changed my mind, it's adapted to the current evolutions, not flooding
> bitcoin with 2 txs while only 1 is needed
>
> If not the best 1 tx solution is super simple: store in addresses, and
> super bad at the end because burning bitcoins, while still not expensive if
> you don't need to store big things"
>
> Le 05/02/2023 à 19:12, Russell O'Connor via bitcoin-dev a écrit :
>
>
>
> On Sat., Feb. 4, 2023, 21:01 Peter Todd, <pete@petertodd.org> wrote:
>
>>
>>
>> On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via
>> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >Since bytes in the witness are cheaper than bytes in the script pubkey,
>> >there is a crossover point in data size where it will simply be cheaper
>> to
>> >use witness data.  Where that crossover point is depends on the finer
>> >details of the overhead of the two methods, but you could make some
>> >reasonable assumptions.  Such a calculation could form the basis of a
>> >reasonable OP_RETURN proposal.  I don't know if it would be persuasive,
>> but
>> >it would at least be coherent.
>>
>> I don't think it's worth the technical complexity trying to carefully
>> argue a specific limit. Let users decide for themselves how they want to
>> use OpReturn.
>>
>
> Even better.
>
>>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> --
> Sophia-Antipolis, France
> CV: https://www.peersm.com/CVAV.pdf
> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
> GitHub : https://www.github.com/Ayms
> A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
> A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
> Peersm : http://www.peersm.com
>
>
> --
> Sophia-Antipolis, France
> CV: https://www.peersm.com/CVAV.pdf
> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
> GitHub : https://www.github.com/Ayms
> A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
> A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
> Peersm : http://www.peersm.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 8894 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 6152 bytes --]

Hi Claus,

Thanks but I am not sure to understand the solution, how the transaction
will look like and will it be standard ?

Regards

Aymeric


Le 16/02/2023 à 20:59, Claus Ehrenberg a écrit :
> I propose to require all data to be in the op_return output PLUS add a
> required op_return_hash field, which is checked by consensus. So that
> node can re-validate the chain without having to store/download/look
> at the contents of op_return data. The benefit of that little
> redundancy is that "content-sensitive" communities can ignore the date
> they don't like.
>
> Cheers
> Claus
>
> On Thu, Feb 16, 2023 at 7:30 PM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     It's super unclear how long it could take for such a change to be
>     adopted
>
>     Then the answer is simple, see:
>     https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation
>
>     Outstandingly, very, mega, bad, but working, bringing bitcoin back
>     10 years ago
>
>     But why not? If bitcoin folks don't get that we need a 1tx storage
>     solution for the future, then let's bring back bitcoin into the
>     past and destroy coins
>
>     Le 12/02/2023 à 17:23, Aymeric Vitte a écrit :
>>
>>     https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403
>>
>>     "What is the process to have someone do the PR for this? Or I do
>>     it and most likely it will be a very shxtty one since I am not a
>>     C/C++ expert, then wasting the time of everybody
>>
>>     It's urgently required, I did consider OP_RETURN as a dart in the
>>     past but changed my mind, it's adapted to the current evolutions,
>>     not flooding bitcoin with 2 txs while only 1 is needed
>>
>>     If not the best 1 tx solution is super simple: store in
>>     addresses, and super bad at the end because burning bitcoins,
>>     while still not expensive if you don't need to store big things"
>>
>>
>>     Le 05/02/2023 à 19:12, Russell O'Connor via bitcoin-dev a écrit :
>>>
>>>
>>>     On Sat., Feb. 4, 2023, 21:01 Peter Todd, <pete@petertodd.org
>>>     <mailto:pete@petertodd.org>> wrote:
>>>
>>>
>>>
>>>         On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor
>>>         via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
>>>         <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>>         >Since bytes in the witness are cheaper than bytes in the
>>>         script pubkey,
>>>         >there is a crossover point in data size where it will
>>>         simply be cheaper to
>>>         >use witness data.  Where that crossover point is depends on
>>>         the finer
>>>         >details of the overhead of the two methods, but you could
>>>         make some
>>>         >reasonable assumptions.  Such a calculation could form the
>>>         basis of a
>>>         >reasonable OP_RETURN proposal.  I don't know if it would be
>>>         persuasive, but
>>>         >it would at least be coherent.
>>>
>>>         I don't think it's worth the technical complexity trying to
>>>         carefully argue a specific limit. Let users decide for
>>>         themselves how they want to use OpReturn.
>>>
>>>
>>>     Even better.
>>>
>>>
>>>
>>>     _______________________________________________
>>>     bitcoin-dev mailing list
>>>     bitcoin-dev@lists.linuxfoundation.org
>>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>     -- 
>>     Sophia-Antipolis, France
>>     CV: https://www.peersm.com/CVAV.pdf
>>     LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
>>     GitHub : https://www.github.com/Ayms
>>     A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
>>     A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
>>     Move your coins by yourself (browser version): https://peersm.com/wallet
>>     Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
>>     torrent-live: https://github.com/Ayms/torrent-live
>>     node-Tor : https://www.github.com/Ayms/node-Tor
>>     Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
>>     Peersm : http://www.peersm.com
>
>     -- 
>     Sophia-Antipolis, France
>     CV: https://www.peersm.com/CVAV.pdf
>     LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
>     GitHub : https://www.github.com/Ayms
>     A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
>     A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
>     Move your coins by yourself (browser version): https://peersm.com/wallet
>     Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
>     torrent-live: https://github.com/Ayms/torrent-live
>     node-Tor : https://www.github.com/Ayms/node-Tor
>     Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
>     Peersm : http://www.peersm.com
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com


[-- Attachment #2: Type: text/html, Size: 13071 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Sat, Feb 04, 2023 at 07:11:35PM -0500, Russell O'Connor via bitcoin-dev wrote:
> Since bytes in the witness are cheaper than bytes in the script pubkey,
> there is a crossover point in data size where it will simply be cheaper to
> use witness data.  Where that crossover point is depends on the finer
> details of the overhead of the two methods, but you could make some
> reasonable assumptions.  Such a calculation could form the basis of a
> reasonable OP_RETURN proposal.  I don't know if it would be persuasive, but
> it would at least be coherent.
>

I agree with Peter that, given that users have found ways to store arbitrary
amounts of data on-chain if they really want, we might as well just make
OP_RETURN a free-for-all.

-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Anthony Towns]

On Sat, Feb 04, 2023 at 07:11:35PM -0500, Russell O'Connor via bitcoin-dev wrote:
> Since bytes in the witness are cheaper than bytes in the script pubkey,
> there is a crossover point in data size where it will simply be cheaper to
> use witness data.

Given today's standardness constraints, that's true (because you first
need to construct a p2wsh/tapscript output that commits to the data,
then you have to spend it), but it needn't stay that way. Allowing a data
carrier entry in the annex (as contemplated for eltoo [0]) would allow
you to publish the data with a single transaction, with malleability
prevented because the annex content is committed to by the signature.

[0] https://github.com/bitcoin-inquisition/bitcoin/pull/22

I think the cost for publishing data via the witness today is roughly:

  115 vb - for the commitment tx
  115 vb + datalen/4 - for the publication tx

versus

  125 vb + datalen - for a tx with an OP_RETURN output

so the crossover point is at a datalen of about 140 bytes. Perhaps
slightly more or less depending on how much you can combine these
inputs/outputs with other txs you would have made anyway.

With a datacarrier in the annex that has similar or higher limits than
OP_RETURN, I don't think OP_RETURN would ever be cheaper.

The other advantage to using the witness for random data compared to
OP_RETURN is that the txid commits to OP_RETURN output, so you must
download all OP_RETURN data to validate a block's merkle tree, whereas
you can partially validate a block (in particular, you can validate the
spendable utxo set) without downloading witness data [1].

[1] https://github.com/bitcoin/bitcoin/pull/27050

Cheers,
aj

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte]

So with datacarrier we can store data in taproot annex with one tx which
will be data and/or extension of the script validation via PUSH_ANNEX

I looked at your links and plenty of others, but had some hard time to
find the proposal
(https://github.com/bitcoin/bips/blob/9dc3f74b384f143b7f1bdad30dc0fe2529c8e63f/bip-annex.mediawiki
I suppose), when do you think datacarrier can happen for real on the
network?

Now I think the OP_RETURN debate remains relevant, it's a quite trivial
modification to do, from my standpoint it is certainly not intended to
store big things (but 80B, what do you want to do with this?), but if
people want to store big things and pay for it... what is the real
issue? (I saw your argument of "partial" block validation and others
like skipping witness data, at the end nodes must validate the whole thing)


Le 17/02/2023 à 13:49, Anthony Towns a écrit :
> On Sat, Feb 04, 2023 at 07:11:35PM -0500, Russell O'Connor via bitcoin-dev wrote:
>> Since bytes in the witness are cheaper than bytes in the script pubkey,
>> there is a crossover point in data size where it will simply be cheaper to
>> use witness data.
> Given today's standardness constraints, that's true (because you first
> need to construct a p2wsh/tapscript output that commits to the data,
> then you have to spend it), but it needn't stay that way. Allowing a data
> carrier entry in the annex (as contemplated for eltoo [0]) would allow
> you to publish the data with a single transaction, with malleability
> prevented because the annex content is committed to by the signature.
>
> [0] https://github.com/bitcoin-inquisition/bitcoin/pull/22
>
> I think the cost for publishing data via the witness today is roughly:
>
>   115 vb - for the commitment tx
>   115 vb + datalen/4 - for the publication tx
>
> versus
>
>   125 vb + datalen - for a tx with an OP_RETURN output
>
> so the crossover point is at a datalen of about 140 bytes. Perhaps
> slightly more or less depending on how much you can combine these
> inputs/outputs with other txs you would have made anyway.
>
> With a datacarrier in the annex that has similar or higher limits than
> OP_RETURN, I don't think OP_RETURN would ever be cheaper.
>
> The other advantage to using the witness for random data compared to
> OP_RETURN is that the txid commits to OP_RETURN output, so you must
> download all OP_RETURN data to validate a block's merkle tree, whereas
> you can partially validate a block (in particular, you can validate the
> spendable utxo set) without downloading witness data [1].
>
> [1] https://github.com/bitcoin/bitcoin/pull/27050
>
> Cheers,
> aj

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com