1  Return-Path: <mbde@bitwatch.co>
 2  Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
 3  	[172.17.192.35])
 4  	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5A09EBC3
 5  	for <bitcoin-dev@lists.linuxfoundation.org>;
 6  	Thu,  4 Jan 2018 19:38:27 +0000 (UTC)
 7  X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
 8  Received: from dd32718.kasserver.com (dd32718.kasserver.com [85.13.150.64])
 9  	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9F528E0
10  	for <bitcoin-dev@lists.linuxfoundation.org>;
11  	Thu,  4 Jan 2018 19:38:26 +0000 (UTC)
12  Received: from [192.168.178.48] (p5DDF8839.dip0.t-ipconnect.de [93.223.136.57])
13  	by dd32718.kasserver.com (Postfix) with ESMTPSA id 853074DC02B4
14  	for <bitcoin-dev@lists.linuxfoundation.org>;
15  	Thu,  4 Jan 2018 20:38:24 +0100 (CET)
16  To: bitcoin-dev@lists.linuxfoundation.org
17  References: <567cdb19-f5b3-6058-9b5b-8a891558d9d5@bitwatch.co>
18  From: "mbde@bitwatch.co" <mbde@bitwatch.co>
19  Message-ID: <10fe1a88-af34-4c4e-a0f2-8d618ca04f5a@bitwatch.co>
20  Date: Thu, 4 Jan 2018 20:38:23 +0100
21  User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
22  	Thunderbird/52.5.2
23  MIME-Version: 1.0
24  In-Reply-To: <567cdb19-f5b3-6058-9b5b-8a891558d9d5@bitwatch.co>
25  Content-Type: text/plain; charset=utf-8
26  Content-Transfer-Encoding: 7bit
27  X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
28  	version=3.3.1
29  X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
30  	smtp1.linux-foundation.org
31  X-Mailman-Approved-At: Thu, 04 Jan 2018 19:43:09 +0000
32  Subject: Re: [bitcoin-dev] Raise default datacarriersize to 220 byte or
33  	higher
34  X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
35  X-Mailman-Version: 2.1.12
36  Precedence: list
37  List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
38  List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
39  	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
40  List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
41  List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
42  List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
43  List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
44  	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
45  X-List-Received-Date: Thu, 04 Jan 2018 19:38:27 -0000
46  
47  To add some information about the relevance of this:
48  
49  During December 2017 there were roughly 210.000 Omni Layer transactions,
50  with more than 12.000 transactions on peak days, and the numbers are
51  growing.
52  
53  I assume there is a similar number of Counterparty transactions, which
54  most likely benefit from additional payload space, too.
55  
56  mbde--- via bitcoin-dev wrote:
57  > Hi guys,
58  > 
59  > there are several ways to embed arbitrary data into the blockchain, and
60  > this is used by several meta-protocols. Most protocols at this point use
61  > OP_RETURN scripts for this.
62  > 
63  > To disincentivize the use of other and more harmful methods to embed
64  > data into the chain, in particular via P2SH, I propose to raise the
65  > default datacarriersize to 220 byte, so it becomes the "cheapest" way of
66  > embedding data into the chain.
67  > 
68  > The following graph shows the relation between transaction sizes and
69  > payload sizes: http://i.imgur.com/VAGZWBK.png
70  > 
71  > Embedding data with bare-multisig and P2SH can be cheaper in terms of
72  > effective transaction size, compared to OP_RETURN with a payload limit
73  > of 80 byte. Both methods of embedding data, via bare-multisig and P2SH,
74  > were heavily used by the major two meta-protocols on top of Bitcoin:
75  > Omni and Counterparty, but both protocols started to use OP_RETRUN data
76  > embedding a long time ago.
77  > 
78  > However, currently token sends are usually done one by one, each with a
79  > single transaction, and this is a heavy burden for the whole network,
80  > e.g. when an exchange sends out withdrawals.
81  > 
82  > We have solutions for "multi-sends with multi-inputs" and also
83  > considered moving destinations into the payload for token sends, but we
84  > need more space, otherwise this solution is limited to very few recipients.
85  > 
86  > I therefore propose to raise the default datacarriersize to 220 byte or
87  > higher and I'd be happy to provide a pull request doing so, if this gets
88  > positive feedback.
89  > 
90  > - dexx
91  > _______________________________________________
92  > bitcoin-dev mailing list
93  > bitcoin-dev@lists.linuxfoundation.org
94  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
95  > 
96