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

* [Bitcoin-development] Increasing the OP_RETURN maximum payload size
@ 2014-11-16 16:21 Flavien Charlon
  2014-11-16 17:24 ` Luke Dashjr
  2014-11-17 10:30 ` Wladimir
  0 siblings, 2 replies; 17+ messages in thread
From: Flavien Charlon @ 2014-11-16 16:21 UTC (permalink / raw)
  To: Bitcoin Dev

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

Hi,

The data that can be embedded as part of an OP_RETURN output is currently
limited to 40 bytes. It was initially supposed to be 80 bytes, but got
reduced to 40 before the 0.9 release to err on the side of caution.

After 9 months, it seems OP_RETURN did not lead to a blockchain
catastrophe, so I think it might be time to discuss increasing the limit.

There are a number of proposals:

   1. Allow two OP_RETURN outputs per transaction (PR
   <https://github.com/bitcoin/bitcoin/pull/5075>)
   2. Increase the default maximum payload size from 40 bytes to 80 bytes (
   PR <https://github.com/bitcoin/bitcoin/pull/5286>)
   Note that the maximum can be configured already through the
   'datacarriersize' option - this is just changing the default.
   3. Make the maximum OP_RETURN payload size proportional to the number of
   outputs of the transaction
   4. A combination of the above

3 sounds the most interesting, and 2 would be the second best.

1 is also good to have as long as the "space budget" is shared between the
two outputs.

Can we discuss this and agree on a plan?

Thanks,
Flavien

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

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

• * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
    2014-11-16 16:21 [Bitcoin-development] Increasing the OP_RETURN maximum payload size Flavien Charlon
  @ 2014-11-16 17:24 ` Luke Dashjr
    2014-11-16 18:44   ` Jorge Timón
    2014-11-17 10:30 ` Wladimir
    1 sibling, 1 reply; 17+ messages in thread
  From: Luke Dashjr @ 2014-11-16 17:24 UTC (permalink / raw)
    To: bitcoin-development; +Cc: Flavien Charlon
  
  On Sunday, November 16, 2014 4:21:27 PM Flavien Charlon wrote:
  > The data that can be embedded as part of an OP_RETURN output is currently
  > limited to 40 bytes. It was initially supposed to be 80 bytes, but got
  > reduced to 40 before the 0.9 release to err on the side of caution.
  > 
  > After 9 months, it seems OP_RETURN did not lead to a blockchain
  > catastrophe, so I think it might be time to discuss increasing the limit.
  
  Mining policies such as this is always up to miners.
  It's not a development topic.
  
  > There are a number of proposals:
  > 
  >    1. Allow two OP_RETURN outputs per transaction (PR
  >    <https://github.com/bitcoin/bitcoin/pull/5075>)
  
  This one seems uselessly inefficient. Protocols needing OP_RETURN could just 
  as easily look for an independent push opcode in a single OP_RETURN output.
  
  >    2. Increase the default maximum payload size from 40 bytes to 80 bytes (
  >    PR <https://github.com/bitcoin/bitcoin/pull/5286>)
  >    Note that the maximum can be configured already through the
  >    'datacarriersize' option - this is just changing the default.
  
  I don't care strongly, but IMO this kind of focus on defaults is part of the 
  problem. I'd prefer to have the default be randomised to incentivise miners to 
  make the decision they're supposed to be making, rather than pushing the 
  responsibility onto developers to set defaults.
  
  >    3. Make the maximum OP_RETURN payload size proportional to the number of
  >    outputs of the transaction
  
  Right now, this policy requires code hacks. Of the three ideas, this one looks 
  the most ripe for code changes (particularly one that makes it possible to 
  configure this policy, not hardcoding it).
  
  Luke
  
  
  
  ^ permalink raw reply	[flat|nested] 17+ messages in thread

• • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
      2014-11-16 17:24 ` Luke Dashjr
    @ 2014-11-16 18:44   ` Jorge Timón
      2014-11-16 19:04     ` Jorge Timón
      0 siblings, 1 reply; 17+ messages in thread
    From: Jorge Timón @ 2014-11-16 18:44 UTC (permalink / raw)
      To: Luke Dashjr; +Cc: Bitcoin Dev, Flavien Charlon
    
    I agree with Luke, we can endlessly discuss the "best defaults" like
    the default size allowed for OP_RETURN, minimum fees, anti-dust
    policies, first-seen vs replace-by-fee, etc; but the fact is that
    policies depend on miners. Unfortunately most miners and pools are
    quite apathetic when it comes to configure their own policy.
    In my opinion the best we can do is to make it easier for miners to
    implement their own policies by abstracting out those parts of the
    code. Pull requests like #5071 and #5114 are steps in that direction.
    So if you're interested in having more miners accepting 80 bytes
    OP_RETURN transactions, I suggest you invest some time reviewing and
    testing those PRs.
    Although this wasn't its main purpose, separating script/standard was
    also a little step in the same direction.
    
    
    
    ^ permalink raw reply	[flat|nested] 17+ messages in thread

  • • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
        2014-11-16 18:44   ` Jorge Timón
      @ 2014-11-16 19:04     ` Jorge Timón
        2014-11-17  3:19       ` Alan Reiner
        0 siblings, 1 reply; 17+ messages in thread
      From: Jorge Timón @ 2014-11-16 19:04 UTC (permalink / raw)
        To: Luke Dashjr; +Cc: Bitcoin Dev, Flavien Charlon
      
      As an aside, the decision to make it 40 bytes made sense because it is
      enough for timestamping. In fact, you can do cheaper and even secret
      (and thus impossible to censor by miners) timestamping using
      pay-to-contract [1], which uses exactly 0 extra bytes in your
      transaction and the blockchain.
      I remember people asking in #bitcoin-dev "Does anyone know any use
      case for greater sizes OP_RETURNs?" and me answering "I do not know of
      any use cases that require bigger sizes".
      I'm aware that so called "proof of publication" is not equivalent to
      timestamping, but I wasn't aware at the moment (and I don't think it's
      very interesting but that's obviously only my opinion, "embedded
      systems" developers will disagree).
      
      [1] Here's a video explaining pay-to-contract in the context of
      invoicing as a use case: https://www.youtube.com/watch?v=qwyALGlG33Q
      Here's a generic working implementation:
      https://github.com/Blockstream/contracthashtool
      
      
      On Sun, Nov 16, 2014 at 7:44 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
      > I agree with Luke, we can endlessly discuss the "best defaults" like
      > the default size allowed for OP_RETURN, minimum fees, anti-dust
      > policies, first-seen vs replace-by-fee, etc; but the fact is that
      > policies depend on miners. Unfortunately most miners and pools are
      > quite apathetic when it comes to configure their own policy.
      > In my opinion the best we can do is to make it easier for miners to
      > implement their own policies by abstracting out those parts of the
      > code. Pull requests like #5071 and #5114 are steps in that direction.
      > So if you're interested in having more miners accepting 80 bytes
      > OP_RETURN transactions, I suggest you invest some time reviewing and
      > testing those PRs.
      > Although this wasn't its main purpose, separating script/standard was
      > also a little step in the same direction.
      
      
      
      ^ permalink raw reply	[flat|nested] 17+ messages in thread

    • • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
          2014-11-16 19:04     ` Jorge Timón
        @ 2014-11-17  3:19       ` Alan Reiner
          2014-11-17 10:35         ` Pieter Wuille
          0 siblings, 1 reply; 17+ messages in thread
        From: Alan Reiner @ 2014-11-17  3:19 UTC (permalink / raw)
          To: bitcoin-development
        
        
        On 11/16/2014 02:04 PM, Jorge Timón wrote:
        > I remember people asking in #bitcoin-dev "Does anyone know any use
        > case for greater sizes OP_RETURNs?" and me answering "I do not know of
        > any use cases that require bigger sizes".
        
        For reference, there was a brief time where I was irritated that the
        size had been reduced to 40 bytes, because I had an application where I
        wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
        need at least 64 bytes for that.   Unfortunately I can't remember now
        what that application was, so it's difficult for me to argue for it. 
        But I don't think that's an unreasonable use case:  sending a payment
        with a signature, essentially all timestamped in the blockchain.
        
        
        
        
        
        ^ permalink raw reply	[flat|nested] 17+ messages in thread

      • • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
            2014-11-17  3:19       ` Alan Reiner
          @ 2014-11-17 10:35         ` Pieter Wuille
            2014-11-17 11:20           ` Adam Back
            2014-11-17 11:43           ` Flavien Charlon
            0 siblings, 2 replies; 17+ messages in thread
          From: Pieter Wuille @ 2014-11-17 10:35 UTC (permalink / raw)
            To: Alan Reiner; +Cc: Bitcoin Dev
          
          On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner <etotheipi@gmail•com> wrote:
          >
          > On 11/16/2014 02:04 PM, Jorge Timón wrote:
          >> I remember people asking in #bitcoin-dev "Does anyone know any use
          >> case for greater sizes OP_RETURNs?" and me answering "I do not know of
          >> any use cases that require bigger sizes".
          >
          > For reference, there was a brief time where I was irritated that the
          > size had been reduced to 40 bytes, because I had an application where I
          > wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
          > need at least 64 bytes for that.   Unfortunately I can't remember now
          > what that application was, so it's difficult for me to argue for it.
          > But I don't think that's an unreasonable use case:  sending a payment
          > with a signature, essentially all timestamped in the blockchain.
          
          You can still send the signature out of band (for example using the
          payment protocol), and just have the transaction commit to a hash of
          that signature (or message in general), either using an OP_RETURN
          output to store the hash, or using the pay-to-contract scheme that
          Jorge mentioned above. That has exactly the same timestamping
          properties.
          
          My main concern with OP_RETURN is that it seems to encourage people to
          use the blockchain as a convenient transport channel, rather than just
          for data that the world needs to see to validate it. I'd rather
          encourage solutions that don't require additional data there, which in
          many cases (but not all) is perfectly possible.
          
          -- 
          Pieter
          
          
          
          ^ permalink raw reply	[flat|nested] 17+ messages in thread

        • • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
              2014-11-17 10:35         ` Pieter Wuille
            @ 2014-11-17 11:20           ` Adam Back
              2014-11-17 12:31             ` Chris Pacia
              2014-11-17 11:43           ` Flavien Charlon
              1 sibling, 1 reply; 17+ messages in thread
            From: Adam Back @ 2014-11-17 11:20 UTC (permalink / raw)
              To: Pieter Wuille; +Cc: Bitcoin Dev
            
            It seems to me that people maybe arriving at the idea that they should
            put transaction data in the blockchain for three related reasons: a)
            its there and its convenient; and b) they are thinking about permanent
            storage and being able to recover from backup using a master seed to a
            bip32 address-set and want that logic to extend to the extra features;
            c) they are thinking out of band, but they think they are forced to
            send the data there in order to achieve atomicity.
            
            I think the data that is sent on the blockchain is design-compressed
            minimal necessary to achieve transaction integrity, and its important
            for scalability that we keep it that way.  About the rationales for
            using that scarce scalability impacting channel:
            
            a) convenience: is not a great reason to my mind. there are lots of
            channels: email, web forms, point2point various transports NFC, TCP,
            HTTP for payment protocol or extensions or new protocols.  I think
            there could be a need for a reliable privacy preserving store and
            forward decentralised infrastructure to act as a channel for such
            purposes.  Until then email could be pretty convenient, if you dont
            get the message due to spam filter etc ask them to resend.  Or a web
            storage locker related to the app.
            
            b) backup: the blockchain is not an efficient reliable generic backup
            mechanism because its broadcast.  there are cheaper and relatively
            simple ways to get end2end secure backup, the main challenge of which
            is having secure keys and not forgetting them.  bitcoin already has
            that covered as its a central requirement of blockchain security.  If
            you want to archive your payment protocol receipts store them on some
            cloud storage service or disk encrypted with related keys.  for
            example tahoe-lafs is optimised for the decentralised long-term
            storage kind of use.
            
            c) atomicity. as an example application requiring atomicity that may
            use op_return stealth addresses where if the stealth auxiliary message
            was sent out of band, then if message is lost, and the sender didnt
            keep it or cant be relied on to care, then the money could be
            permanently lost to both parties.
            
            It occurred to me recently the kind of use requiring atomicity as
            stealth address in c) can be achieved by sending both the extra
            message (the stealth packet) AND the signed bitcoin transaction over
            the reliable store & forward (eg email for now).  Then the recipient
            can do the calculations involving the auxiliary message and payment
            message, and relay the message to the blockchain IFF they receive the
            message (and chose to accept it).  If they dont receive the message
            they can ask for it to be resent.  And if the payment is unclaimed the
            sender still owns it and can double-spend to avoid risk of later
            spending in their replacement message, or double-spend to self if the
            recipient declines the payment.  This has privacy, efficiency and SPV
            advantages over sending to the blockchain.
            
            I think we could make a case that as a design principle auxiliary data
            could do with a bitcoin-related but separate reliable store and
            forward channel, as email has been sufficiently spammed to end up with
            loss of reliability.  So I think a payment message transport would be
            good here: invoices & receipts, and other things necessary for
            applications, transaction disputes, records for normal p2p trades and
            business functions reliable store and forward substrate with
            decentralisation & privacy. For email the existing mechanism with
            closest semantics, add-on privacy features exist: mixmaster,
            nymservers, webmail + encryption, webmail over Tor etc for privacy
            related uses.  Slow transports can offer better security than
            interactive transports.
            
            Adam
            
            On 17 November 2014 10:35, Pieter Wuille <pieter.wuille@gmail•com> wrote:
            > On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner <etotheipi@gmail•com> wrote:
            >>
            >> On 11/16/2014 02:04 PM, Jorge Timón wrote:
            >>> I remember people asking in #bitcoin-dev "Does anyone know any use
            >>> case for greater sizes OP_RETURNs?" and me answering "I do not know of
            >>> any use cases that require bigger sizes".
            >>
            >> For reference, there was a brief time where I was irritated that the
            >> size had been reduced to 40 bytes, because I had an application where I
            >> wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
            >> need at least 64 bytes for that.   Unfortunately I can't remember now
            >> what that application was, so it's difficult for me to argue for it.
            >> But I don't think that's an unreasonable use case:  sending a payment
            >> with a signature, essentially all timestamped in the blockchain.
            >
            > You can still send the signature out of band (for example using the
            > payment protocol), and just have the transaction commit to a hash of
            > that signature (or message in general), either using an OP_RETURN
            > output to store the hash, or using the pay-to-contract scheme that
            > Jorge mentioned above. That has exactly the same timestamping
            > properties.
            >
            > My main concern with OP_RETURN is that it seems to encourage people to
            > use the blockchain as a convenient transport channel, rather than just
            > for data that the world needs to see to validate it. I'd rather
            > encourage solutions that don't require additional data there, which in
            > many cases (but not all) is perfectly possible.
            >
            > --
            > Pieter
            >
            > ------------------------------------------------------------------------------
            > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
            > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
            > with Interactivity, Sharing, Native Excel Exports, App Integration & more
            > Get technology previously reserved for billion-dollar corporations, FREE
            > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
            > _______________________________________________
            > Bitcoin-development mailing list
            > Bitcoin-development@lists•sourceforge.net
            > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
            
            
            
            ^ permalink raw reply	[flat|nested] 17+ messages in thread

          • • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
                2014-11-17 11:20           ` Adam Back
              @ 2014-11-17 12:31             ` Chris Pacia
                2014-11-17 12:39               ` Pieter Wuille
                0 siblings, 1 reply; 17+ messages in thread
              From: Chris Pacia @ 2014-11-17 12:31 UTC (permalink / raw)
                To: bitcoin-development
              
              [-- Attachment #1: Type: text/plain, Size: 1836 bytes --]
              
              
              On 11/17/2014 06:20 AM, Adam Back wrote:
              > b) backup: the blockchain is not an efficient reliable generic backup
              > mechanism because its broadcast.  there are cheaper and relatively
              > simple ways to get end2end secure backup, the main challenge of which
              > is having secure keys and not forgetting them.  bitcoin already has
              > that covered as its a central requirement of blockchain security.  If
              > you want to archive your payment protocol receipts store them on some
              > cloud storage service or disk encrypted with related keys.  for
              > example tahoe-lafs is optimised for the decentralised long-term
              > storage kind of use.
              >
              This is my main concern in the context of stealth addresses. I intend to
              start a larger discussion on stealth addresses, but I wont hijack the
              tread.
              
              Of course it's easy to send the necessary data out of band as opposed to
              OP_RETURN. The problem is if you do that the transaction cannot not be
              recovered from seed. We've been fairly successful in transitioning to HD
              wallets and avoiding the need to make regular wallet backups.
              
              If users wishes to use stealth addresses with out of band communication,
              the benefits of HD would largely be lost and they would be back to
              making regular backups ― this time after /every/ transaction rather than
              every 100.
              
              There are only a couple options in such cases:
              
              1) The user could send the payment to an addresses that is derived from
              seed, but now you're using even /more/ storage space than you would by
              just using OP_RETURN.
              
              2) The user can backup after every transaction, which nobody wants to do.
              
              3) The user could use some form of a cloud backup service and place
              trust in them that their servers wont go down and lose their coins.
              
              None of those options are really that appealing. OP_RETURN seems like
              the best alternative to me, at least for that use case.
              
              [-- Attachment #2: Type: text/html, Size: 2390 bytes --]
              
              ^ permalink raw reply	[flat|nested] 17+ messages in thread

            • • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
                  2014-11-17 12:31             ` Chris Pacia
                @ 2014-11-17 12:39               ` Pieter Wuille
                  2014-11-18 22:33                 ` Chris Pacia
                  0 siblings, 1 reply; 17+ messages in thread
                From: Pieter Wuille @ 2014-11-17 12:39 UTC (permalink / raw)
                  To: Chris Pacia; +Cc: Bitcoin Dev
                
                On Mon, Nov 17, 2014 at 1:31 PM, Chris Pacia <ctpacia@gmail•com> wrote:
                > If users wishes to use stealth addresses with out of band communication, the
                > benefits of HD would largely be lost and they would be back to making
                > regular backups -- this time after every transaction rather than every 100.
                
                
                That is inevitable for any wallet that offers any functionality beyond
                just maintaining a balance and the ability to send coins. In
                particular, anything that wishes to list previous transaction (with
                timestamps, history, metadata, messages sent using the payment
                protocol, ...) needs backups.
                
                What HD wallets (or any type of deterministic derivation scheme) offer
                is the fact that you can separate secret data and public data. You
                only need one safe backup of the master secret key - all the rest can
                at most result in privacy loss and not in lost coins.
                
                -- 
                Pieter
                
                
                
                ^ permalink raw reply	[flat|nested] 17+ messages in thread

              • • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
                    2014-11-17 12:39               ` Pieter Wuille
                  @ 2014-11-18 22:33                 ` Chris Pacia
                    0 siblings, 0 replies; 17+ messages in thread
                  From: Chris Pacia @ 2014-11-18 22:33 UTC (permalink / raw)
                    To: Pieter Wuille; +Cc: Bitcoin Dev
                  
                  [-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
                  
                  On Nov 17, 2014 7:39 AM, "Pieter Wuille" <pieter.wuille@gmail•com> wrote:
                  
                  > That is inevitable for any wallet that offers any functionality beyond
                  > just maintaining a balance and the ability to send coins. In
                  > particular, anything that wishes to list previous transaction (with
                  > timestamps, history, metadata, messages sent using t
                  > What HD wallets (or any type of deterministic derivation scheme) offer
                  > is the fact that you can separate secret data and public data. You
                  > only need one safe backup of the master secret key - all the rest can
                  > at most result in privacy loss and not in lost coins.
                  >
                  > --
                  > Pieter
                  
                  I agree but right now wallets not using stealth will only lose metadata,
                  not coins, if their computer crashes and they have the seed backed up.
                  
                  But if a user wants to upgrade to stealth, they then risk losing metadata
                  AND coins if they either didn't manually back up after every transaction or
                  use a centralized cloud backup service.
                  
                  That's if OP_RETURN is not utilized for storage.
                  
                  [-- Attachment #2: Type: text/html, Size: 1238 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 17+ messages in thread

          • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
              2014-11-17 10:35         ` Pieter Wuille
              2014-11-17 11:20           ` Adam Back
            @ 2014-11-17 11:43           ` Flavien Charlon
              2014-11-17 12:00             ` Pieter Wuille
                                           ` (2 more replies)
              1 sibling, 3 replies; 17+ messages in thread
            From: Flavien Charlon @ 2014-11-17 11:43 UTC (permalink / raw)
              To: Pieter Wuille; +Cc: Bitcoin Dev
            
            [-- Attachment #1: Type: text/plain, Size: 3982 bytes --]
            
            > My main concern with OP_RETURN is that it seems to encourage people to
            use the blockchain as a convenient transport channel
            
            The number one user of the blockchain as a storage and transport mechanism
            is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them
            from doing so. In fact they use multi-sig outputs which is worse than
            OP_RETURN since it's not always prunable, and yet let them store much more
            than 40 bytes.
            
            For Open Assets <https://github.com/OpenAssets/open-assets-protocol>, we
            need to store a URL in the OP_RETURN output (with optionally a hash) plus
            some bytes of overhead. 40 bytes comes really short for that. The benefit
            of having a URL in there is that any storage mechanism can be used (Web,
            FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to
            hardcode the storing mechanism in the protocol (and even then, a hash is
            not enough to address a HTTP or FTP resource). Storing only a hash is fine
            for the most basic timestamping application, but it's hardly enough to
            build something interesting.
            
            I've counted the number of OP_RETURN outputs in the blockchain for the
            month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659
            blocks. Assuming they were all 40 bytes (the average is probably less than
            half of that), that means an increase of 14.37 bytes per block. Considering
            a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data
            in average.
            
            Increasing to 80 bytes will have a negligible impact on bandwidth and
            storage requirements, while being extremely useful for many use cases where
            a hash only is not enough.
            
            Flavien
            
            On Mon, Nov 17, 2014 at 10:35 AM, Pieter Wuille <pieter.wuille@gmail•com>
            wrote:
            
            > On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner <etotheipi@gmail•com> wrote:
            > >
            > > On 11/16/2014 02:04 PM, Jorge Timón wrote:
            > >> I remember people asking in #bitcoin-dev "Does anyone know any use
            > >> case for greater sizes OP_RETURNs?" and me answering "I do not know of
            > >> any use cases that require bigger sizes".
            > >
            > > For reference, there was a brief time where I was irritated that the
            > > size had been reduced to 40 bytes, because I had an application where I
            > > wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
            > > need at least 64 bytes for that.   Unfortunately I can't remember now
            > > what that application was, so it's difficult for me to argue for it.
            > > But I don't think that's an unreasonable use case:  sending a payment
            > > with a signature, essentially all timestamped in the blockchain.
            >
            > You can still send the signature out of band (for example using the
            > payment protocol), and just have the transaction commit to a hash of
            > that signature (or message in general), either using an OP_RETURN
            > output to store the hash, or using the pay-to-contract scheme that
            > Jorge mentioned above. That has exactly the same timestamping
            > properties.
            >
            > My main concern with OP_RETURN is that it seems to encourage people to
            > use the blockchain as a convenient transport channel, rather than just
            > for data that the world needs to see to validate it. I'd rather
            > encourage solutions that don't require additional data there, which in
            > many cases (but not all) is perfectly possible.
            >
            > --
            > Pieter
            >
            >
            > ------------------------------------------------------------------------------
            > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
            > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
            > with Interactivity, Sharing, Native Excel Exports, App Integration & more
            > Get technology previously reserved for billion-dollar corporations, FREE
            >
            > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
            > _______________________________________________
            > Bitcoin-development mailing list
            > Bitcoin-development@lists•sourceforge.net
            > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
            >
            
            [-- Attachment #2: Type: text/html, Size: 5105 bytes --]
            
            ^ permalink raw reply	[flat|nested] 17+ messages in thread

          • • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
                2014-11-17 11:43           ` Flavien Charlon
              @ 2014-11-17 12:00             ` Pieter Wuille
                2014-11-17 12:22             ` Jorge Timón
                2014-11-18 17:47             ` Btc Drak
                2 siblings, 0 replies; 17+ messages in thread
              From: Pieter Wuille @ 2014-11-17 12:00 UTC (permalink / raw)
                To: Flavien Charlon; +Cc: Bitcoin Dev
              
              On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon
              <flavien.charlon@coinprism•com> wrote:
              >> My main concern with OP_RETURN is that it seems to encourage people to use
              >> the blockchain as a convenient transport channel
              >
              > The number one user of the blockchain as a storage and transport mechanism
              > is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them from
              > doing so. In fact they use multi-sig outputs which is worse than OP_RETURN
              > since it's not always prunable, and yet let them store much more than 40
              > bytes.
              
              It wasn't limited to stop them from using it. It was limited to avoid
              giving others the impression that OP_RETURN was intended for data
              storage. For the intended purpose (making a transaction commit to some
              external data) a 32-byte hash + 8 byte id is more than sufficient.
              
              > For Open Assets, we need to store a URL in the OP_RETURN output (with
              > optionally a hash) plus some bytes of overhead. 40 bytes comes really short
              > for that. The benefit of having a URL in there is that any storage mechanism
              > can be used (Web, FTP, BitTorrent, MaidSafe...), whereas with only a hash,
              > you have to hardcode the storing mechanism in the protocol (and even then, a
              > hash is not enough to address a HTTP or FTP resource). Storing only a hash
              > is fine for the most basic timestamping application, but it's hardly enough
              > to build something interesting.
              
              Do you really need that data published to everyone? You're at the very
              least exposing yourself to censorship, and (depending on the design)
              potentially decreased privacy for your users. I would expect that for
              most colored coin applications, just having the color transfer
              information in external data sent directly to the receiver with
              transactions committing to it should suffice.
              
              -- 
              Pieter
              
              
              
              ^ permalink raw reply	[flat|nested] 17+ messages in thread

            • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
                2014-11-17 11:43           ` Flavien Charlon
                2014-11-17 12:00             ` Pieter Wuille
              @ 2014-11-17 12:22             ` Jorge Timón
                2014-11-18 17:47             ` Btc Drak
                2 siblings, 0 replies; 17+ messages in thread
              From: Jorge Timón @ 2014-11-17 12:22 UTC (permalink / raw)
                To: Flavien Charlon; +Cc: Bitcoin Dev
              
              On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon
              <flavien.charlon@coinprism•com> wrote:
              > Storing only a hash
              > is fine for the most basic timestamping application, but it's hardly enough
              > to build something interesting.
              
              No, storing only a hash is enough for ALL timestamping applications.
              If you need to broadcast more data then we're not talking about
              timestamping anymore, but rather proof of publication.
              Unfortunately (and as it has been already mentioned) many applications
              don't need proof of publication and yet they are just using the
              blockchain as a convenient transport mechanism, but that's highly
              inefficient.
              It's like if you sent all your mails to all the existing email
              addresses with the metadata "to be read by: destination@yourhost•com".
              It wouldn't make any sense and it wouldn't scale.
              A url definitely looks like something that doesn't belong in the chain.
              
              
              
              ^ permalink raw reply	[flat|nested] 17+ messages in thread

            • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
                2014-11-17 11:43           ` Flavien Charlon
                2014-11-17 12:00             ` Pieter Wuille
                2014-11-17 12:22             ` Jorge Timón
              @ 2014-11-18 17:47             ` Btc Drak
                2014-11-19  0:46               ` Flavien Charlon
                2 siblings, 1 reply; 17+ messages in thread
              From: Btc Drak @ 2014-11-18 17:47 UTC (permalink / raw)
                To: Flavien Charlon; +Cc: Bitcoin Dev
              
              [-- Attachment #1: Type: text/plain, Size: 2225 bytes --]
              
              On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon <
              flavien.charlon@coinprism•com> wrote:
              
              > > My main concern with OP_RETURN is that it seems to encourage people to
              > use the blockchain as a convenient transport channel
              >
              > The number one user of the blockchain as a storage and transport mechanism
              > is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them
              > from doing so. In fact they use multi-sig outputs which is worse than
              > OP_RETURN since it's not always prunable, and yet let them store much more
              > than 40 bytes.
              >
              > For Open Assets <https://github.com/OpenAssets/open-assets-protocol>, we
              > need to store a URL in the OP_RETURN output (with optionally a hash) plus
              > some bytes of overhead. 40 bytes comes really short for that. The benefit
              > of having a URL in there is that any storage mechanism can be used (Web,
              > FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to
              > hardcode the storing mechanism in the protocol (and even then, a hash is
              > not enough to address a HTTP or FTP resource). Storing only a hash is fine
              > for the most basic timestamping application, but it's hardly enough to
              > build something interesting.
              >
              > I've counted the number of OP_RETURN outputs in the blockchain for the
              > month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659
              > blocks. Assuming they were all 40 bytes (the average is probably less than
              > half of that), that means an increase of 14.37 bytes per block. Considering
              > a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data
              > in average.
              >
              > Increasing to 80 bytes will have a negligible impact on bandwidth and
              > storage requirements, while being extremely useful for many use cases where
              > a hash only is not enough.
              >
              
              While I am not opposing the proposal, I am not sure about your statistics
              because while Counterparty is not currently using OP_RETURN encoding, you
              should factor in the number of CP transactions that would have been
              OP_RETURNs if they had been permitted (100,000 since inception according
              their blog[1] with monthly charts at their block explorer[2]).
              
              Refs:
              [1]
              http://counterparty.io/news/celebrating-100000-transaction-on-the-counterparty-network/
              [2] http://blockscan.com/
              
              [-- Attachment #2: Type: text/html, Size: 3017 bytes --]
              
              ^ permalink raw reply	[flat|nested] 17+ messages in thread

            • • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
                  2014-11-18 17:47             ` Btc Drak
                @ 2014-11-19  0:46               ` Flavien Charlon
                  0 siblings, 0 replies; 17+ messages in thread
                From: Flavien Charlon @ 2014-11-19  0:46 UTC (permalink / raw)
                  To: Btc Drak; +Cc: Bitcoin Dev
                
                [-- Attachment #1: Type: text/plain, Size: 2986 bytes --]
                
                >
                > While I am not opposing the proposal, I am not sure about your statistics
                > because while Counterparty is not currently using OP_RETURN encoding, you
                > should factor in the number of CP transactions that would have been
                > OP_RETURNs if they had been permitted (100,000 since inception according
                > their blog[1] with monthly charts at their block explorer[2]).
                
                
                Sure, but even if they are not permitted to store their data in OP_RETURN,
                they will still store it in the blockchain in bare multisig outputs, so
                it's not contributing to an overhead (in fact, it would consume less space
                in the blockchain if they used OP_RETURN).
                
                On Tue, Nov 18, 2014 at 5:47 PM, Btc Drak <btcdrak@gmail•com> wrote:
                
                > On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon <
                > flavien.charlon@coinprism•com> wrote:
                >
                >> > My main concern with OP_RETURN is that it seems to encourage people to
                >> use the blockchain as a convenient transport channel
                >>
                >> The number one user of the blockchain as a storage and transport
                >> mechanism is Counterparty, and limiting OP_RETURN to 40 bytes didn't
                >> prevent them from doing so. In fact they use multi-sig outputs which is
                >> worse than OP_RETURN since it's not always prunable, and yet let them store
                >> much more than 40 bytes.
                >>
                >> For Open Assets <https://github.com/OpenAssets/open-assets-protocol>, we
                >> need to store a URL in the OP_RETURN output (with optionally a hash) plus
                >> some bytes of overhead. 40 bytes comes really short for that. The benefit
                >> of having a URL in there is that any storage mechanism can be used (Web,
                >> FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to
                >> hardcode the storing mechanism in the protocol (and even then, a hash is
                >> not enough to address a HTTP or FTP resource). Storing only a hash is fine
                >> for the most basic timestamping application, but it's hardly enough to
                >> build something interesting.
                >>
                >> I've counted the number of OP_RETURN outputs in the blockchain for the
                >> month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659
                >> blocks. Assuming they were all 40 bytes (the average is probably less than
                >> half of that), that means an increase of 14.37 bytes per block. Considering
                >> a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN
                >> data in average.
                >>
                >> Increasing to 80 bytes will have a negligible impact on bandwidth and
                >> storage requirements, while being extremely useful for many use cases where
                >> a hash only is not enough.
                >>
                >
                > While I am not opposing the proposal, I am not sure about your statistics
                > because while Counterparty is not currently using OP_RETURN encoding, you
                > should factor in the number of CP transactions that would have been
                > OP_RETURNs if they had been permitted (100,000 since inception according
                > their blog[1] with monthly charts at their block explorer[2]).
                >
                > Refs:
                > [1]
                > http://counterparty.io/news/celebrating-100000-transaction-on-the-counterparty-network/
                > [2] http://blockscan.com/
                >
                >
                
                [-- Attachment #2: Type: text/html, Size: 4217 bytes --]
                
                ^ permalink raw reply	[flat|nested] 17+ messages in thread

• * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
    2014-11-16 16:21 [Bitcoin-development] Increasing the OP_RETURN maximum payload size Flavien Charlon
    2014-11-16 17:24 ` Luke Dashjr
  @ 2014-11-17 10:30 ` Wladimir
    2014-11-20 23:39   ` Jean-Pierre Rupp
    1 sibling, 1 reply; 17+ messages in thread
  From: Wladimir @ 2014-11-17 10:30 UTC (permalink / raw)
    To: Flavien Charlon; +Cc: Bitcoin Dev
  
  On Sun, Nov 16, 2014 at 5:21 PM, Flavien Charlon
  <flavien.charlon@coinprism•com> wrote:
  > Hi,
  >
  > The data that can be embedded as part of an OP_RETURN output is currently
  > limited to 40 bytes. It was initially supposed to be 80 bytes, but got
  > reduced to 40 before the 0.9 release to err on the side of caution.
  >
  > After 9 months, it seems OP_RETURN did not lead to a blockchain catastrophe,
  
  Agreed. I'm in favor of increasing OP_RETURN size as well. Don't care
  about the actual size.
  
  (rationale: pruning is going to land soonish, and everything is better
  than UTXO-polluting methods that encode everything into addresses such
  as now used by cryptograffiti)
  
  Wladimir
  
  
  
  ^ permalink raw reply	[flat|nested] 17+ messages in thread

• • * Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
      2014-11-17 10:30 ` Wladimir
    @ 2014-11-20 23:39   ` Jean-Pierre Rupp
      0 siblings, 0 replies; 17+ messages in thread
    From: Jean-Pierre Rupp @ 2014-11-20 23:39 UTC (permalink / raw)
      To: Wladimir, Flavien Charlon; +Cc: Bitcoin Dev
    
    [-- Attachment #1: Type: text/plain, Size: 668 bytes --]
    
    Agree,
    
    There are many legitimate uses for a larger OP_RETURN, and application developers are already complaining that the current size is not enough.  It is about adding value to the blockchain.  I know it can grow the blockchain faster, but so far at 40 bytes Bitcoin hasn't experienced death by bloat, nor that is even close to happen.  I understand starting with a prudent approach, but I think it is safe to increase this without worrying.  Actually I would make it even bigger than 80 bytes.
    
    Cheers
    
    On 17/11/14 02:30, Wladimir wrote:
    > Agreed. I'm in favor of increasing OP_RETURN size as well. Don't care
    > about the actual size.
    
    -- 
    Be Happy :)
    
    [-- Attachment #2: 0x310A8A5B.asc --]
    [-- Type: application/pgp-keys, Size: 4648 bytes --]
    
    [-- Attachment #3: root.vcf --]
    [-- Type: text/x-vcard, Size: 215 bytes --]
    
    begin:vcard
    fn:Jean-Pierre Rupp
    n:Rupp;Jean-Pierre
    org:Haskoin
    email;internet:root@haskoin•com
    title:Co-Founder
    tel;work:+353862720509
    x-mozilla-html:FALSE
    url:http://haskoin.com/
    version:2.1
    end:vcard
    
    
    ^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2014-11-20 23:39 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-16 16:21 [Bitcoin-development] Increasing the OP_RETURN maximum payload size Flavien Charlon
2014-11-16 17:24 ` Luke Dashjr
2014-11-16 18:44   ` Jorge Timón
2014-11-16 19:04     ` Jorge Timón
2014-11-17  3:19       ` Alan Reiner
2014-11-17 10:35         ` Pieter Wuille
2014-11-17 11:20           ` Adam Back
2014-11-17 12:31             ` Chris Pacia
2014-11-17 12:39               ` Pieter Wuille
2014-11-18 22:33                 ` Chris Pacia
2014-11-17 11:43           ` Flavien Charlon
2014-11-17 12:00             ` Pieter Wuille
2014-11-17 12:22             ` Jorge Timón
2014-11-18 17:47             ` Btc Drak
2014-11-19  0:46               ` Flavien Charlon
2014-11-17 10:30 ` Wladimir
2014-11-20 23:39   ` Jean-Pierre Rupp

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