public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "mbde@bitwatch.co" <mbde@bitwatch.co>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Raise default datacarriersize to 220 byte or higher
Date: Thu, 4 Jan 2018 20:38:23 +0100	[thread overview]
Message-ID: <10fe1a88-af34-4c4e-a0f2-8d618ca04f5a@bitwatch.co> (raw)
In-Reply-To: <567cdb19-f5b3-6058-9b5b-8a891558d9d5@bitwatch.co>

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
> 


      reply	other threads:[~2018-01-04 19:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-04  9:37 [bitcoin-dev] Raise default datacarriersize to 220 byte or higher mbde
2018-01-04 19:38 ` mbde [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10fe1a88-af34-4c4e-a0f2-8d618ca04f5a@bitwatch.co \
    --to=mbde@bitwatch.co \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox