public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
@ 2023-02-01  0:46 Christopher Allen
  2023-02-01  2:07 ` Peter Todd
                   ` (2 more replies)
  0 siblings, 3 replies; 34+ messages in thread
From: Christopher Allen @ 2023-02-01  0:46 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- 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 --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

• * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
    2023-02-01  0:46 [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH Christopher Allen
  @ 2023-02-01  2:07 ` Peter Todd
    2023-02-01  2:22   ` Christopher Allen
    2023-02-01 14:02   ` Andrew Poelstra
    2023-02-01 12:59 ` Aymeric Vitte
    2023-02-02 13:25 ` Rijndael
    2 siblings, 2 replies; 34+ messages in thread
  From: Peter Todd @ 2023-02-01  2:07 UTC (permalink / raw)
    To: Christopher Allen, Bitcoin Protocol Discussion,
  	Christopher Allen via bitcoin-dev
  
  
  
  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.
  
  
  ^ permalink raw reply	[flat|nested] 34+ messages in thread

• • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
      2023-02-01  2:07 ` Peter Todd
    @ 2023-02-01  2:22   ` Christopher Allen
      2023-02-01  8:36     ` Kostas Karasavvas
      2023-02-01 14:02   ` Andrew Poelstra
      1 sibling, 1 reply; 34+ messages in thread
    From: Christopher Allen @ 2023-02-01  2:22 UTC (permalink / raw)
      To: Peter Todd; +Cc: Christopher Allen via bitcoin-dev
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 34+ messages in thread

  • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
        2023-02-01  2:22   ` Christopher Allen
      @ 2023-02-01  8:36     ` Kostas Karasavvas
        2023-02-01 12:51       ` Peter Todd
        0 siblings, 1 reply; 34+ messages in thread
      From: Kostas Karasavvas @ 2023-02-01  8:36 UTC (permalink / raw)
        To: Christopher Allen, Bitcoin Protocol Discussion
      
      [-- 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 --]
      
      ^ permalink raw reply	[flat|nested] 34+ messages in thread

    • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
          2023-02-01  8:36     ` Kostas Karasavvas
        @ 2023-02-01 12:51       ` Peter Todd
          0 siblings, 0 replies; 34+ messages in thread
        From: Peter Todd @ 2023-02-01 12:51 UTC (permalink / raw)
          To: Kostas Karasavvas, Christopher Allen, Bitcoin Protocol Discussion
        
        
        
        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.
        
        
        ^ permalink raw reply	[flat|nested] 34+ messages in thread

  • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
      2023-02-01  2:07 ` Peter Todd
      2023-02-01  2:22   ` Christopher Allen
    @ 2023-02-01 14:02   ` Andrew Poelstra
      2023-02-02 11:22     ` Peter Todd
      1 sibling, 1 reply; 34+ messages in thread
    From: Andrew Poelstra @ 2023-02-01 14:02 UTC (permalink / raw)
      To: Peter Todd, Bitcoin Protocol Discussion
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 34+ messages in thread

  • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
        2023-02-01 14:02   ` Andrew Poelstra
      @ 2023-02-02 11:22     ` Peter Todd
        2023-02-02 11:45       ` Aymeric Vitte
        0 siblings, 1 reply; 34+ messages in thread
      From: Peter Todd @ 2023-02-02 11:22 UTC (permalink / raw)
        To: Andrew Poelstra; +Cc: Bitcoin Protocol Discussion
      
      [-- 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 --]
      
      ^ permalink raw reply	[flat|nested] 34+ messages in thread

    • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
          2023-02-02 11:22     ` Peter Todd
        @ 2023-02-02 11:45       ` Aymeric Vitte
          2023-02-02 11:49         ` Peter Todd
          0 siblings, 1 reply; 34+ messages in thread
        From: Aymeric Vitte @ 2023-02-02 11:45 UTC (permalink / raw)
          To: Peter Todd, Bitcoin Protocol Discussion, Andrew Poelstra
        
        [-- 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 --]
        
        ^ permalink raw reply	[flat|nested] 34+ messages in thread

      • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
            2023-02-02 11:45       ` Aymeric Vitte
          @ 2023-02-02 11:49         ` Peter Todd
            2023-02-02 12:24           ` Aymeric Vitte
            0 siblings, 1 reply; 34+ messages in thread
          From: Peter Todd @ 2023-02-02 11:49 UTC (permalink / raw)
            To: Aymeric Vitte; +Cc: Bitcoin Protocol Discussion
          
          [-- 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 --]
          
          ^ permalink raw reply	[flat|nested] 34+ messages in thread

        • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
              2023-02-02 11:49         ` Peter Todd
            @ 2023-02-02 12:24           ` Aymeric Vitte
              0 siblings, 0 replies; 34+ messages in thread
            From: Aymeric Vitte @ 2023-02-02 12:24 UTC (permalink / raw)
              To: Peter Todd; +Cc: Bitcoin Protocol Discussion
            
            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
            
            
            
            ^ permalink raw reply	[flat|nested] 34+ messages in thread

• * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
    2023-02-01  0:46 [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH Christopher Allen
    2023-02-01  2:07 ` Peter Todd
  @ 2023-02-01 12:59 ` Aymeric Vitte
    2023-02-02 13:25 ` Rijndael
    2 siblings, 0 replies; 34+ messages in thread
  From: Aymeric Vitte @ 2023-02-01 12:59 UTC (permalink / raw)
    To: Christopher Allen, Bitcoin Protocol Discussion
  
  [-- 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 --]
  
  ^ permalink raw reply	[flat|nested] 34+ messages in thread

• * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
    2023-02-01  0:46 [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH Christopher Allen
    2023-02-01  2:07 ` Peter Todd
    2023-02-01 12:59 ` Aymeric Vitte
  @ 2023-02-02 13:25 ` Rijndael
    2023-02-03 11:15   ` Aymeric Vitte
    2 siblings, 1 reply; 34+ messages in thread
  From: Rijndael @ 2023-02-02 13:25 UTC (permalink / raw)
    To: bitcoin-dev
  
  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
  >
  
  
  
  ^ permalink raw reply	[flat|nested] 34+ messages in thread

• • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
      2023-02-02 13:25 ` Rijndael
    @ 2023-02-03 11:15   ` Aymeric Vitte
      2023-02-03 18:47     ` Christopher Allen
      0 siblings, 1 reply; 34+ messages in thread
    From: Aymeric Vitte @ 2023-02-03 11:15 UTC (permalink / raw)
      To: Rijndael, Bitcoin Protocol Discussion
    
    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
    
    
    
    
    ^ permalink raw reply	[flat|nested] 34+ messages in thread

  • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
        2023-02-03 11:15   ` Aymeric Vitte
      @ 2023-02-03 18:47     ` Christopher Allen
        2023-02-04 14:11       ` Kostas Karasavvas
        0 siblings, 1 reply; 34+ messages in thread
      From: Christopher Allen @ 2023-02-03 18:47 UTC (permalink / raw)
        To: Aymeric Vitte, Bitcoin Protocol Discussion
      
      [-- 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 --]
      
      ^ permalink raw reply	[flat|nested] 34+ messages in thread

    • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
          2023-02-03 18:47     ` Christopher Allen
        @ 2023-02-04 14:11       ` Kostas Karasavvas
          2023-02-04 17:01         ` Aymeric Vitte
          0 siblings, 1 reply; 34+ messages in thread
        From: Kostas Karasavvas @ 2023-02-04 14:11 UTC (permalink / raw)
          To: Christopher Allen, Bitcoin Protocol Discussion
        
        [-- 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 --]
        
        ^ permalink raw reply	[flat|nested] 34+ messages in thread

      • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
            2023-02-04 14:11       ` Kostas Karasavvas
          @ 2023-02-04 17:01         ` Aymeric Vitte
            2023-02-04 18:54           ` Christopher Allen
            0 siblings, 1 reply; 34+ messages in thread
          From: Aymeric Vitte @ 2023-02-04 17:01 UTC (permalink / raw)
            To: Kostas Karasavvas, Bitcoin Protocol Discussion, Christopher Allen
          
          [-- 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 --]
          
          ^ permalink raw reply	[flat|nested] 34+ messages in thread

        • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
              2023-02-04 17:01         ` Aymeric Vitte
            @ 2023-02-04 18:54           ` Christopher Allen
              2023-02-04 20:55             ` Aymeric Vitte
              0 siblings, 1 reply; 34+ messages in thread
            From: Christopher Allen @ 2023-02-04 18:54 UTC (permalink / raw)
              To: Aymeric Vitte; +Cc: Bitcoin Protocol Discussion
            
            [-- 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 --]
            
            ^ permalink raw reply	[flat|nested] 34+ messages in thread

          • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                2023-02-04 18:54           ` Christopher Allen
              @ 2023-02-04 20:55             ` Aymeric Vitte
                2023-02-04 22:18               ` Christopher Allen
                0 siblings, 1 reply; 34+ messages in thread
              From: Aymeric Vitte @ 2023-02-04 20:55 UTC (permalink / raw)
                To: Christopher Allen; +Cc: Bitcoin Protocol Discussion
              
              [-- 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 --]
              
              ^ permalink raw reply	[flat|nested] 34+ messages in thread

            • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                  2023-02-04 20:55             ` Aymeric Vitte
                @ 2023-02-04 22:18               ` Christopher Allen
                  2023-02-04 23:09                 ` Aymeric Vitte
                  0 siblings, 1 reply; 34+ messages in thread
                From: Christopher Allen @ 2023-02-04 22:18 UTC (permalink / raw)
                  To: Aymeric Vitte; +Cc: Bitcoin Protocol Discussion
                
                [-- 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 --]
                
                ^ permalink raw reply	[flat|nested] 34+ messages in thread

              • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                    2023-02-04 22:18               ` Christopher Allen
                  @ 2023-02-04 23:09                 ` Aymeric Vitte
                    2023-02-05  0:04                   ` Peter Todd
                    2023-02-05  0:11                   ` Russell O'Connor
                    0 siblings, 2 replies; 34+ messages in thread
                  From: Aymeric Vitte @ 2023-02-04 23:09 UTC (permalink / raw)
                    To: Christopher Allen; +Cc: Bitcoin Protocol Discussion
                  
                  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).
                  
                  
                  
                  
                  ^ permalink raw reply	[flat|nested] 34+ messages in thread

                • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                      2023-02-04 23:09                 ` Aymeric Vitte
                    @ 2023-02-05  0:04                   ` Peter Todd
                      2023-02-05 11:40                     ` Aymeric Vitte
                      2023-02-05  0:11                   ` Russell O'Connor
                      1 sibling, 1 reply; 34+ messages in thread
                    From: Peter Todd @ 2023-02-05  0:04 UTC (permalink / raw)
                      To: Aymeric Vitte, Bitcoin Protocol Discussion,
                    	Aymeric Vitte via bitcoin-dev, Christopher Allen
                    
                    
                    
                    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.
                    
                    
                    ^ permalink raw reply	[flat|nested] 34+ messages in thread

                  • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                        2023-02-05  0:04                   ` Peter Todd
                      @ 2023-02-05 11:40                     ` Aymeric Vitte
                        2023-02-05 12:06                       ` Peter Todd
                        0 siblings, 1 reply; 34+ messages in thread
                      From: Aymeric Vitte @ 2023-02-05 11:40 UTC (permalink / raw)
                        To: Peter Todd, Bitcoin Protocol Discussion, Christopher Allen
                      
                      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
                      
                      
                      
                      
                      ^ permalink raw reply	[flat|nested] 34+ messages in thread

                    • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                          2023-02-05 11:40                     ` Aymeric Vitte
                        @ 2023-02-05 12:06                       ` Peter Todd
                          2023-02-05 12:47                         ` Aymeric Vitte
                          0 siblings, 1 reply; 34+ messages in thread
                        From: Peter Todd @ 2023-02-05 12:06 UTC (permalink / raw)
                          To: Aymeric Vitte, Bitcoin Protocol Discussion, Christopher Allen
                        
                        
                        
                        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.
                        
                        
                        ^ permalink raw reply	[flat|nested] 34+ messages in thread

                      • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                            2023-02-05 12:06                       ` Peter Todd
                          @ 2023-02-05 12:47                         ` Aymeric Vitte
                            0 siblings, 0 replies; 34+ messages in thread
                          From: Aymeric Vitte @ 2023-02-05 12:47 UTC (permalink / raw)
                            To: Peter Todd, Bitcoin Protocol Discussion, Christopher Allen
                          
                          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
                          
                          
                          
                          ^ permalink raw reply	[flat|nested] 34+ messages in thread

                  • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                      2023-02-04 23:09                 ` Aymeric Vitte
                      2023-02-05  0:04                   ` Peter Todd
                    @ 2023-02-05  0:11                   ` Russell O'Connor
                      2023-02-05  2:01                     ` Peter Todd
                                                           ` (2 more replies)
                      1 sibling, 3 replies; 34+ messages in thread
                    From: Russell O'Connor @ 2023-02-05  0:11 UTC (permalink / raw)
                      To: Aymeric Vitte; +Cc: Bitcoin Protocol Discussion
                    
                    [-- 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 --]
                    
                    ^ permalink raw reply	[flat|nested] 34+ messages in thread

                  • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                        2023-02-05  0:11                   ` Russell O'Connor
                      @ 2023-02-05  2:01                     ` Peter Todd
                        2023-02-05 18:12                       ` Russell O'Connor
                        2023-02-05 18:06                     ` Andrew Poelstra
                        2023-02-17 12:49                     ` Anthony Towns
                        2 siblings, 1 reply; 34+ messages in thread
                      From: Peter Todd @ 2023-02-05  2:01 UTC (permalink / raw)
                        To: Russell O'Connor, Bitcoin Protocol Discussion,
                      	Russell O'Connor via bitcoin-dev, Aymeric Vitte
                      
                      
                      
                      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.
                      
                      
                      ^ permalink raw reply	[flat|nested] 34+ messages in thread

                    • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                          2023-02-05  2:01                     ` Peter Todd
                        @ 2023-02-05 18:12                       ` Russell O'Connor
                          2023-02-12 16:23                         ` Aymeric Vitte
                          0 siblings, 1 reply; 34+ messages in thread
                        From: Russell O'Connor @ 2023-02-05 18:12 UTC (permalink / raw)
                          To: Peter Todd, Russell O'Connor via bitcoin-dev
                        
                        [-- 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 --]
                        
                        ^ permalink raw reply	[flat|nested] 34+ messages in thread

                      • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                            2023-02-05 18:12                       ` Russell O'Connor
                          @ 2023-02-12 16:23                         ` Aymeric Vitte
                            2023-02-16 18:23                           ` Aymeric Vitte
                            0 siblings, 1 reply; 34+ messages in thread
                          From: Aymeric Vitte @ 2023-02-12 16:23 UTC (permalink / raw)
                            To: Russell O'Connor, Bitcoin Protocol Discussion, Peter Todd,
                          	Andrew Poelstra, Christopher Allen
                          
                          [-- 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 --]
                          
                          ^ permalink raw reply	[flat|nested] 34+ messages in thread

                        • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                              2023-02-12 16:23                         ` Aymeric Vitte
                            @ 2023-02-16 18:23                           ` Aymeric Vitte
                              2023-02-16 19:59                             ` Claus Ehrenberg
                              0 siblings, 1 reply; 34+ messages in thread
                            From: Aymeric Vitte @ 2023-02-16 18:23 UTC (permalink / raw)
                              To: Russell O'Connor, Bitcoin Protocol Discussion, Peter Todd,
                            	Andrew Poelstra, Christopher Allen
                            
                            [-- 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 --]
                            
                            ^ permalink raw reply	[flat|nested] 34+ messages in thread

                          • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                                2023-02-16 18:23                           ` Aymeric Vitte
                              @ 2023-02-16 19:59                             ` Claus Ehrenberg
                                2023-02-17 10:56                               ` Aymeric Vitte
                                0 siblings, 1 reply; 34+ messages in thread
                              From: Claus Ehrenberg @ 2023-02-16 19:59 UTC (permalink / raw)
                                To: Aymeric Vitte, Bitcoin Protocol Discussion
                              
                              [-- 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 --]
                              
                              ^ permalink raw reply	[flat|nested] 34+ messages in thread

                            • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                                  2023-02-16 19:59                             ` Claus Ehrenberg
                                @ 2023-02-17 10:56                               ` Aymeric Vitte
                                  0 siblings, 0 replies; 34+ messages in thread
                                From: Aymeric Vitte @ 2023-02-17 10:56 UTC (permalink / raw)
                                  To: Claus Ehrenberg, Bitcoin Protocol Discussion
                                
                                [-- 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 --]
                                
                                ^ permalink raw reply	[flat|nested] 34+ messages in thread

                    • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                        2023-02-05  0:11                   ` Russell O'Connor
                        2023-02-05  2:01                     ` Peter Todd
                      @ 2023-02-05 18:06                     ` Andrew Poelstra
                        2023-02-17 12:49                     ` Anthony Towns
                        2 siblings, 0 replies; 34+ messages in thread
                      From: Andrew Poelstra @ 2023-02-05 18:06 UTC (permalink / raw)
                        To: Russell O'Connor, Bitcoin Protocol Discussion
                      
                      [-- 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 --]
                      
                      ^ permalink raw reply	[flat|nested] 34+ messages in thread

                    • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                        2023-02-05  0:11                   ` Russell O'Connor
                        2023-02-05  2:01                     ` Peter Todd
                        2023-02-05 18:06                     ` Andrew Poelstra
                      @ 2023-02-17 12:49                     ` Anthony Towns
                        2023-02-18 18:38                       ` Aymeric Vitte
                        2 siblings, 1 reply; 34+ messages in thread
                      From: Anthony Towns @ 2023-02-17 12:49 UTC (permalink / raw)
                        To: Russell O'Connor, Bitcoin Protocol Discussion
                      
                      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
                      
                      
                      ^ permalink raw reply	[flat|nested] 34+ messages in thread

                    • • * Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
                          2023-02-17 12:49                     ` Anthony Towns
                        @ 2023-02-18 18:38                       ` Aymeric Vitte
                          0 siblings, 0 replies; 34+ messages in thread
                        From: Aymeric Vitte @ 2023-02-18 18:38 UTC (permalink / raw)
                          To: Anthony Towns, Russell O'Connor, Bitcoin Protocol Discussion
                        
                        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
                        
                        
                        
                        
                        ^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2023-02-18 18:38 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-01  0:46 [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH Christopher Allen
2023-02-01  2:07 ` Peter Todd
2023-02-01  2:22   ` Christopher Allen
2023-02-01  8:36     ` Kostas Karasavvas
2023-02-01 12:51       ` Peter Todd
2023-02-01 14:02   ` Andrew Poelstra
2023-02-02 11:22     ` Peter Todd
2023-02-02 11:45       ` Aymeric Vitte
2023-02-02 11:49         ` Peter Todd
2023-02-02 12:24           ` Aymeric Vitte
2023-02-01 12:59 ` Aymeric Vitte
2023-02-02 13:25 ` Rijndael
2023-02-03 11:15   ` Aymeric Vitte
2023-02-03 18:47     ` Christopher Allen
2023-02-04 14:11       ` Kostas Karasavvas
2023-02-04 17:01         ` Aymeric Vitte
2023-02-04 18:54           ` Christopher Allen
2023-02-04 20:55             ` Aymeric Vitte
2023-02-04 22:18               ` Christopher Allen
2023-02-04 23:09                 ` Aymeric Vitte
2023-02-05  0:04                   ` Peter Todd
2023-02-05 11:40                     ` Aymeric Vitte
2023-02-05 12:06                       ` Peter Todd
2023-02-05 12:47                         ` Aymeric Vitte
2023-02-05  0:11                   ` Russell O'Connor
2023-02-05  2:01                     ` Peter Todd
2023-02-05 18:12                       ` Russell O'Connor
2023-02-12 16:23                         ` Aymeric Vitte
2023-02-16 18:23                           ` Aymeric Vitte
2023-02-16 19:59                             ` Claus Ehrenberg
2023-02-17 10:56                               ` Aymeric Vitte
2023-02-05 18:06                     ` Andrew Poelstra
2023-02-17 12:49                     ` Anthony Towns
2023-02-18 18:38                       ` Aymeric Vitte

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox