<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 14, 2016 at 3:45 PM, Johnson Lau <span dir="ltr">&lt;<a target="_blank" href="mailto:jl2012@xbt.hk">jl2012@xbt.hk</a>&gt;</span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div style="word-wrap:break-word">I think that’s too much tech debt just for softforkability.<div><br></div><div>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).</div></div></blockquote><div><br></div><div>One of the problems with fraud proofs is withholding by miners.  It is important that proof of publication/archive nodes check that the miners are actually publishing their blocks.<br><br></div><div>If you place the data in another tree, then care needs to be taken that the merkle path information can be obtained for that tree.<br><br>If an SPV node asks for a run of transactions from an archive node, then the archive node can give the merkle branch for all of those transactions.  The archive node inherently has to check that tree.<br><br></div><div>The question is if there is a way to show that data is not available, but without opening up the network to DOS.  If enough people run full nodes then this isn&#39;t a problem.<br></div> <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div style="word-wrap:break-word"><div> 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.</div></div></blockquote><div><br></div><div>Seems reasonable.  I think the soft-fork would have to have a timeout before actually activating.  That would give SPV clients time to switch over.  <br><br></div><div>That could happen before the vote though, so it isn&#39;t essential.  The SPV clients would have to support both trees and then switch mode.  Ensuring that SPV nodes actually bother would be helped by proving that the network actually intends to soft fork.<br><br></div><div>The SPV client just has to check that every block has at least one of the commitments that it accepts so that it can understand fraud proofs.<br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div style="word-wrap:break-word"><div><br></div><div>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</div><div>weight = n * (total size +  3 * base size) + sigop , with n = 50</div><div>a block may have millions of sigops which is totally unacceptable.</div></div></blockquote><div><br></div><div>You multiplied by the wrong term.<br><br>weight = total size +  3 * base size + n * sigop , with n = 50<br><br></div><div>weight for max block = 8,000,000<br></div><div><br></div><div>That gives a maximum of 8,000,000 / 50 = 160,000 sigops.<br><br></div><div>To get that you would need zero transaction length.  You could get close if you have transactions that just repeat OP_CHECKSIG over and over (or maybe something with OP_CHECKMULTISIG).<br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div style="word-wrap:break-word"><div><br></div><div>On the other hand, if we make n too low, we may allow either too few sigop, or a too big block size.</div><div><br></div><div>Signature aggregation will make this a bigger problem as one signature may spend thousands of sigop</div><div><div class="gmail-h5"><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On 14 Dec 2016, at 20:52, Tier Nolan &lt;<a target="_blank" href="mailto:tier.nolan@gmail.com">tier.nolan@gmail.com</a>&gt; wrote:</div><br class="gmail-m_-7644285980438085242Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 14, 2016 at 10:55 AM, Johnson Lau <span dir="ltr">&lt;<a target="_blank" href="mailto:jl2012@xbt.hk">jl2012@xbt.hk</a>&gt;</span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div style="word-wrap:break-word"><div>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)</div></div></blockquote><div><br></div><div>That&#39;s a good point.<br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div style="word-wrap:break-word"><div>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)</div></div></blockquote><div><br></div><div style="word-wrap:break-word">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.<br><br></div><div style="word-wrap:break-word">It would mean that the block format would have to include the raw transaction, &quot;extra&quot;/tree information and witness data for each transaction.<br><br></div>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.<br><br></div><div class="gmail_quote">On the other hand, CPU cost and storage/network costs are not completely interchangeable.<br><br>Is there anything that would need to be summed fees, raw tx size, weight and sigops that the greater or equal rule wouldn&#39;t cover?<br></div><div class="gmail_quote"><div style="word-wrap:break-word"><br></div>On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev &lt;<a target="_blank" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<div style="word-wrap:break-word"><div><blockquote type="cite"><div><div class="gmail-m_-7644285980438085242h5"><br class="gmail-m_-7644285980438085242m_6699621031753262314Apple-interchange-newline"></div></div><div><div><div class="gmail-m_-7644285980438085242h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr <span dir="ltr">&lt;<a target="_blank" href="mailto:luke@dashjr.org">luke@dashjr.org</a>&gt;</span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-m_-7644285980438085242m_6699621031753262314gmail-">On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote:<br>
&gt; Any new merkle algorithm should use a sum tree for partial validation and<br>
&gt; fraud proofs.<br>
<br>
</span>PR welcome.<br></blockquote><div><br></div><div>Fair enough.  It is pretty basic.<br><br><a target="_blank" href="https://github.com/luke-jr/bips/pull/2">https://github.com/luke-jr/bip<wbr>s/pull/2</a><br><br></div><div>It sums up sigops, block size, block cost (that is &quot;weight&quot; right?) and fees.<br></div></div></div></div></div></div><span>
______________________________<wbr>_________________<br>bitcoin-dev mailing list<br><a target="_blank" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br><a target="_blank" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br></span></div></blockquote></div><br></div></div><br></div></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div>