public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Johnson Lau <jl2012@xbt.hk>
To: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new header format
Date: Wed, 14 Dec 2016 23:45:37 +0800	[thread overview]
Message-ID: <DB6F4DDF-1424-4FC4-84B3-5D16963E8589@xbt.hk> (raw)
In-Reply-To: <CAE-z3OWEkwuxu+LiT1VsWDBnnoi5pQHDDiiKpi7i8oDOtPrB4A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3680 bytes --]

I think that’s 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’t 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’d 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’s 50:1. If we maintain this ratio, and define
weight = n * (total size +  3 * base size) + sigop , with n = 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 <mailto: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 <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 <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 


[-- Attachment #2: Type: text/html, Size: 6497 bytes --]

  reply	other threads:[~2016-12-14 15:45 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
2016-12-14 12:52         ` Tier Nolan
2016-12-14 15:45           ` Johnson Lau [this message]
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=DB6F4DDF-1424-4FC4-84B3-5D16963E8589@xbt.hk \
    --to=jl2012@xbt.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.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