Raise default datacarriersize to 220 byte or higher

Hi guys,

there are several ways to embed arbitrary data into the blockchain, and this is used by several meta-protocols. Most protocols at this point use OP_RETURN scripts for this.

To disincentivize the use of other and more harmful methods to embed data into the chain, in particular via P2SH, I propose to raise the default datacarriersize 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: http://i.imgur.com/VAGZWBK.png

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, but both protocols started to use OP_RETRUN data embedding a long time ago.

However, currently token sends are usually 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 also 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.

- dexx

To add some information about the relevance of this:

During December 2017 there were roughly 210.000 Omni Layer transactions, with more than 12.000 transactions on peak days, and the numbers are growing.

I assume there is a similar number of Counterparty transactions, which most likely benefit from additional payload space, too.

mbde--- via bitcoin-dev wrote:

> Hi guys,
>
> there are several ways to embed arbitrary data into the blockchain, and
> this is used by several meta-protocols. Most protocols at this point use
> OP_RETURN scripts for this.
>
> To disincentivize the use of other and more harmful methods to embed
> data into the chain, in particular via P2SH, I propose to raise the
> default datacarriersize 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: http://i.imgur.com/VAGZWBK.png
>
> 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, but both protocols started to use OP_RETRUN data
> embedding a long time ago.
>
> However, currently token sends are usually 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 also
> 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.
>
> - dexx
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>