Raise default datacarriersize to 220 byte or higher #12033

issue dexX7 openend this issue on December 27, 2017
  1. dexX7 commented at 11:43 am on December 27, 2017: contributor

    To disincentivize the use of other and more harmful methods to embed data into the chain, in particular via P2SH, the default datacarriersize should be raised from 82 byte to 220 byte, so it becomes the “cheapest” way of embedding data into the chain.

    The following graph shows the relation between transaction sizes and payload sizes:

    Embedding data with bare-multisig and P2SH can be cheaper in terms of effective transaction size, compared to OP_RETURN with a payload limit of 80 byte. Both methods of embedding data, via bare-multisig and P2SH, were heavily used by the major two meta-protocols on top of Bitcoin: Omni and Counterparty (see here and here), but both protocols started to use OP_RETRUN data embedding for a long time.

    However, currently token sends are done one by one, each with a single transaction, and this is a heavy burden for the whole network, e.g. when an exchange sends out withdrawals.

    We have solutions for “multi-sends with multi-inputs” and considered moving destinations into the payload for token sends, but we need more space, otherwise this solution is limited to very few recipients.

    I therefore propose to raise the default datacarriersize to 220 byte or higher and I’d be happy to provide a pull request doing so, if this gets positive feedback.

  2. jonasschnelli added the label Brainstorming on Jan 4, 2018
  3. jonasschnelli commented at 6:51 am on January 4, 2018: contributor

    I guess this is a policy (IsStandard) discussion and maybe therefore something we can discuss here on GitHub. But, because it affects other network participants, I recommend to take this to the bitcoin-dev@ mailing list.

    Some history: #5286 #3737 #2738

  4. dexX7 commented at 7:16 am on January 11, 2018: contributor

    Counterparty is going to use P2SH soon due to their need for more space for batched payments, see:

    https://github.com/CounterpartyXCP/cips/blob/master/cip-0006.md https://github.com/chiguireitor/cips/blob/cip10/cip-0010.md

    As announced in their latest blog post.

  5. MarcoFalke commented at 10:26 pm on April 26, 2020: member
    Agree with Jonas that this needs discussion on the mailing list first.
  6. MarcoFalke closed this on Apr 26, 2020

  7. dexX7 commented at 7:05 am on April 27, 2020: contributor
    Hi @MarcoFalke, do you think it’s worth the time to discuss this any further on the ML?
  8. DrahtBot locked this on Feb 15, 2022

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-17 15:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me