From: Johnson Lau <jl2012@xbt.hk>
To: Tier Nolan <tier.nolan@gmail.com>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
Luke Dashjr <luke@dashjr.org>
Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new header format
Date: Wed, 14 Dec 2016 18:55:39 +0800 [thread overview]
Message-ID: <02E75CD7-24A8-4E2F-9466-B5497D0B77F8@xbt.hk> (raw)
In-Reply-To: <CAE-z3OX5QW0jy_ZvU7=onaVoynJrsuyeCdc=q7wj=d5O4XLO7Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]
I think the biggest problem of sum tree is the lack of flexibility to redefine the values with softforks. For example, in the future we may want to define a new CHECKSIG with witness script version 1. That would be counted as a SigOp. Without a sum tree design, that’d be easy as we could just define new SigOp through a softfork (e.g. the introduction of P2SH SigOp, and the witness v0 SigOp). 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)
Similarly, we may have secondary witness in the future, and the tx weight would be redefined with a softfork. We will face the same problem with a sum tree
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)
You could find related discussion here: https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541ee7a17208 <https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541ee7a17208>
Maybe we could make this optional: for nodes running exactly the same rules, they could omit the weight and nSigOp value in transmission. To talk to legacy nodes, they need to transmit the newly defined weight and nSigOp. But this makes script upgrade much complex.
> On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr <luke@dashjr.org <mailto: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 <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 <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 3855 bytes --]
next prev parent reply other threads:[~2016-12-14 10:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-04 19:34 [bitcoin-dev] Forcenet: an experimental network with a new header format Johnson Lau
2016-12-04 20:00 ` adiabat
2016-12-04 20:37 ` Hampus Sjöberg
2016-12-05 11:58 ` Tom Zander
2016-12-14 11:01 ` Johnson Lau
2016-12-14 11:07 ` Luke Dashjr
2016-12-14 11:12 ` Johnson Lau
2016-12-14 11:11 ` Johnson Lau
2016-12-10 21:29 ` Tier Nolan
2016-12-10 21:41 ` Luke Dashjr
2016-12-11 16:40 ` Tier Nolan
2016-12-14 10:55 ` Johnson Lau [this message]
2016-12-14 12:52 ` Tier Nolan
2016-12-14 15:45 ` Johnson Lau
2016-12-14 16:26 ` Tier Nolan
2017-01-14 21:14 ` Johnson Lau
2017-01-28 2:32 ` Matt Corallo
2017-01-28 3:02 ` Matt Corallo
2017-01-28 7:28 ` Johnson Lau
2017-01-28 17:14 ` Matt Corallo
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=02E75CD7-24A8-4E2F-9466-B5497D0B77F8@xbt.hk \
--to=jl2012@xbt.hk \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=luke@dashjr.org \
--cc=tier.nolan@gmail.com \
/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