Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D4E422C for ; Wed, 14 Dec 2016 12:52:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com [209.85.216.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 47207153 for ; Wed, 14 Dec 2016 12:52:15 +0000 (UTC) Received: by mail-qt0-f175.google.com with SMTP id n6so20369952qtd.1 for ; Wed, 14 Dec 2016 04:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EbaXhWMVDL2LX3U6nnwKqKmCR27GK2PEcFlcQbO3qNs=; b=i4rgBRvzWyhUAMg1nInIefhd5a5sqmd7Ff9ZODIk1jL0BLxtlxICXjNr8y5I9OB+G8 HsfYja6aMzAl6Y+ui9GQEbvPjz408HCtsRo6VJzIhsbGwyEcLlT1qvrm70koGrUxnnAu D0csgHBeYGkjJ/PlbhkzsgQSs3TmmE4dVkpIUQLnvWL6sa0iZKGqEdQM1B6+y6SKPjOS 2C2aV9Xuyvc9smsXwa2jhxJ0D1OVYCXp5y8gMz6jrZ+ok81F8kXk9s3+QXLMZfHppwYq Bhs1moqOyfjUtj61Vwtn35clErzxQfCU+lvHzEPURykXKEJ1jyEwwPyC/FAMLJJZK4Ab nIOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EbaXhWMVDL2LX3U6nnwKqKmCR27GK2PEcFlcQbO3qNs=; b=DfErnkl7yb/4jXYHgmAXz/YTBLV411rE0HbuJFswcn2O9VvPzAYA18/F93tGj0Nijm YwYfnhLEPKFxPLOnDWj26yfiM/t/9l4631Rnel2G2+A2s9MvtMUDYrCTeBExAR9kKjD5 xh24RyxZUYEA/TmHfN6BbqVmZ1MGM29jhXmCmkiOotU3AJHnHuIk6jNPE5Ro9ciArd9g N+/EuVtKDk3EmFSusLM0DPLPGx6+Ikuw4c8OrmKIsnSKhpeGqjaQW9q+LNIT6PjGkN5L Bk5QEAZF//QmHZbmb66meTT1etwkKN0rbmT+qYEKPlkyEdwrrTe9guoloi6enKHhnF1t GJfw== X-Gm-Message-State: AKaTC03AvCMROzklQXovrumulNIQAch7Tedp6hXgwzjUJyOaXCMB/lYfrhhqN+rdcZAiqSUSOe7SZOGesyiErQ== X-Received: by 10.200.38.72 with SMTP id v8mr100838001qtv.292.1481719934530; Wed, 14 Dec 2016 04:52:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.52.99 with HTTP; Wed, 14 Dec 2016 04:52:14 -0800 (PST) In-Reply-To: <02E75CD7-24A8-4E2F-9466-B5497D0B77F8@xbt.hk> References: <201612102141.58206.luke@dashjr.org> <02E75CD7-24A8-4E2F-9466-B5497D0B77F8@xbt.hk> From: Tier Nolan Date: Wed, 14 Dec 2016 12:52:14 +0000 Message-ID: To: Johnson Lau Content-Type: multipart/alternative; boundary=001a11410d5a5abba905439dce06 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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 12:52:16 -0000 --001a11410d5a5abba905439dce06 Content-Type: text/plain; charset=UTF-8 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) > 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 wrote: 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. > > 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 --001a11410d5a5abba905439dce06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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 redefinit= ion 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 poi= nt.
=C2=A0
The only way to fix this is to explicitly commit= to the weight and nSigOp, and the committed value must be equal to or larg= er 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 int= 64 are used)

The weight and sigop count could be transmitted as variable le= ngth integers.=C2=A0 That would be around 2 bytes for the sigops and 3 byte= s 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 t= ransaction.

On an unrelated note, the two costs could be combi= ned into a unified cost.=C2=A0 For example, a sigop could have equal cost t= o 250 bytes.=C2=A0 This would make it easier for miners to decide what to c= harge.

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

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

On 12 Dec 20= 16, at 00:40, Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.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.=C2=A0 I= t is pretty basic.

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

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


--001a11410d5a5abba905439dce06--