Why Nostr? What is Njump?
2023-06-07 18:09:12
in reply to

mbde at bitwatch.co [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-04 📝 Original message:To add some information ...

📅 Original date posted:2018-01-04
📝 Original message: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:
>
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Author Public Key
npub1g9fwx8qpkdpdlz86jmghzr35m60723a4crec0k8trsh3ue794njsvshjlm