Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D13FCB6B for ; Wed, 14 Dec 2016 15:45:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A956BD5 for ; Wed, 14 Dec 2016 15:45:49 +0000 (UTC) Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by mx.zohomail.com with SMTPS id 1481730341136520.0080372076295; Wed, 14 Dec 2016 07:45:41 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FB5945C7-6573-4111-B774-636C74A57867" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Johnson Lau In-Reply-To: Date: Wed, 14 Dec 2016 23:45:37 +0800 Message-Id: References: <201612102141.58206.luke@dashjr.org> <02E75CD7-24A8-4E2F-9466-B5497D0B77F8@xbt.hk> To: Tier Nolan X-Mailer: Apple Mail (2.3124) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new header format X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 15:45:50 -0000 --Apple-Mail=_FB5945C7-6573-4111-B774-636C74A57867 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think that=E2=80=99s too much tech debt just for softforkability. The better way would be making the sum tree as an independent tree with = a separate commitment, and define a special type of softfork (e.g. a = special BIP9 bit). When the softfork is activated, the legacy full node = will stop validating the sum tree. This doesn=E2=80=99t really degrade = the security by more than a normal softfork, as the legacy full node = would still validate the total weight and nSigOp based on its own rules. = The only purpose of the sum tree is to help SPV nodes to validate. This = way we could even completely redefine the structure and data committed = in the sum tree. I=E2=80=99d like to combine the size weight and sigOp weight, but not = sure if we could. The current size weight limit is 4,000,000 and sigop = limit is 80,000. It=E2=80=99s 50:1. If we maintain this ratio, and = define weight =3D n * (total size + 3 * base size) + sigop , with n =3D 50 a block may have millions of sigops which is totally unacceptable. On the other hand, if we make n too low, we may allow either too few = sigop, or a too big block size. Signature aggregation will make this a bigger problem as one signature = may spend thousands of sigop > On 14 Dec 2016, at 20:52, Tier Nolan wrote: >=20 >=20 >=20 > On Wed, Dec 14, 2016 at 10:55 AM, Johnson Lau > wrote: > In a sum tree, however, since the nSigOp is implied, any redefinition = requires either a hardfork or a new sum tree (and the original sum tree = becomes a placebo for old nodes. So every softfork of this type creates = a new tree) >=20 > That's a good point. > =20 > The only way to fix this is to explicitly commit to the weight and = nSigOp, and the committed value must be equal to or larger than the real = value. Only in this way we could redefine it with softfork. However, = that means each tx will have an overhead of 16 bytes (if two int64 are = used) >=20 > The weight and sigop count could be transmitted as variable length = integers. That would be around 2 bytes for the sigops and 3 bytes for = the weight, per transaction. >=20 > It would mean that the block format would have to include the raw = transaction, "extra"/tree information and witness data for each = transaction. >=20 > On an unrelated note, the two costs could be combined into a unified = cost. For example, a sigop could have equal cost to 250 bytes. This = would make it easier for miners to decide what to charge. >=20 > On the other hand, CPU cost and storage/network costs are not = completely interchangeable. >=20 > Is there anything that would need to be summed fees, raw tx size, = weight and sigops that the greater or equal rule wouldn't cover? >=20 > On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev = > wrote: >>=20 >> On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr > wrote: >> On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev = wrote: >> > Any new merkle algorithm should use a sum tree for partial = validation and >> > fraud proofs. >>=20 >> PR welcome. >>=20 >> Fair enough. It is pretty basic. >>=20 >> https://github.com/luke-jr/bips/pull/2 = >>=20 >> It sums up sigops, block size, block cost (that is "weight" right?) = and fees. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org = >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = >=20 >=20 --Apple-Mail=_FB5945C7-6573-4111-B774-636C74A57867 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think that=E2=80=99s too much tech debt just for = softforkability.

The = better way would be making the sum tree as an independent tree with a = separate commitment, and define a special type of softfork (e.g. a = special BIP9 bit). When the softfork is activated, the legacy full node = will stop validating the sum tree. This doesn=E2=80=99t really degrade = the security by more than a normal softfork, as the legacy full node = would still validate the total weight and nSigOp based on its own rules. = The only purpose of the sum tree is to help SPV nodes to validate. This = way we could even completely redefine the structure and data committed = in the sum tree.

I=E2=80=99d like to combine the size weight and sigOp weight, = but not sure if we could. The current size weight limit is 4,000,000 and = sigop limit is 80,000. It=E2=80=99s 50:1. If we maintain this ratio, and = define
weight =3D n * (total size +  3 * base = size) + sigop , with n =3D 50
a block may have = millions of sigops which is totally unacceptable.
On the other hand, if we make n too = low, we may allow either too few sigop, or a too big block = size.

Signature = aggregation will make this a bigger problem as one signature may spend = thousands of sigop



On = 14 Dec 2016, at 20:52, Tier Nolan <tier.nolan@gmail.com> wrote:



On Wed, Dec 14, 2016 at 10:55 AM, Johnson Lau = <jl2012@xbt.hk> wrote:
In a sum tree, = however, since the nSigOp is implied, any redefinition requires either a = hardfork or a new sum tree (and the original sum tree becomes a placebo = for old nodes. So every softfork of this type creates a new = tree)

That's a good point.
 
The only way = to fix this is to explicitly commit to the weight and nSigOp, and the = committed value must be equal to or larger than the real value. Only in = this way we could redefine it with softfork. However, that means each tx = will have an overhead of 16 bytes (if two int64 are = used)

The weight and sigop count = could be transmitted as variable length integers.  That would be = around 2 bytes for the sigops and 3 bytes for the weight, per = transaction.

It would mean that the block = format would have to include the raw transaction, "extra"/tree = information and witness data for each transaction.

On an unrelated note, the two costs could be combined = into a unified cost.  For example, a sigop could have equal cost to = 250 bytes.  This would make it easier for miners to decide what to = charge.

On = the other hand, CPU cost and storage/network costs are not completely = interchangeable.

Is there anything that = would need to be summed fees, raw tx size, weight and sigops that the = greater or equal rule wouldn't cover?

On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> wrote:

On Sat, = Dec 10, 2016 at 9:41 PM, Luke Dashjr <luke@dashjr.org> wrote:
On Saturday, December 10, 2016 = 9:29:09 PM Tier Nolan via bitcoin-dev wrote:
> Any new merkle algorithm should use a sum tree for partial = validation and
> fraud proofs.

PR welcome.

Fair enough.  It is pretty = basic.

https://github.com/luke-jr/bips/pull/2

It sums up sigops, block = size, block cost (that is "weight" right?) and fees.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



= --Apple-Mail=_FB5945C7-6573-4111-B774-636C74A57867--