@edward is on PowPing!

PowPing is a place where you can earn Bitcoin simply by socializing, for FREE.
Never tried Bitcoin? It's OK! Just come, socialize, and earn Bitcoin.
Check out edward's activities

BSV中文交流

visit channel home
Total Economy: 0.03 USD
请问,在BCH改成LTOR后,在组装区块时,随着新交易不断加入,计算Merkle tree的成本是不是会比TTOR要高? 参考 http://bitcointoken.com/blog-concerns-with-ltor 中 Creating a new valid block 这一节。
如果加入新的交易就要重新排序然后再重新计算一次全部的默克尔树的话,这个确实是成本挺高的。 虽然很多人认为,矿工在添加交易,收取手续费的时候需要在第一个 Coinbase 交易里面修改数额,但实际上我们依然可以通过这样的策略来进行优化: 在 Coinbase 交易中添加一个略大于手续费的收款交易; 在最后一笔交易中支付 Coinbase 奖励-(区块其他交易总手续费+区块补贴) 的差额,使区块总手续费等于 Coinbase 全额。 这样我们就可以在相当长的时间内保持 Coinbase 交易不变,而只需要在最后添加新的交易即可。甚至连全部重算默克尔树的功夫都省了。
edward tipped:
0.02 USD
1 year ago
edward replied:
这地方我有些疑问,Brendan的开发者大会的PPT里coinbase tx放到最右侧(最后)计算的,视频链接(https://youtube.com/watch?v=hi7XOqPeDKs
自己增加一个tx补差额的办法真有创意。这样即使往merkele树里增加一批新的tx,也只用修改老树的少数一些非叶子节点,改动很少,性能很好。
linzheming replied:
我觉得我的方法更好,且更容易验证。我不知道 coinbase tx 放在最后是否破坏了共识体系对于 coinbase tx 的识别。目前我觉得,每次添加交易反正都要修改 coinbase tx 来收手续费的,这个可以转去计算最后一个 fee collector 的交易就行。但是有一个额外的签名的成本(coinbase tx 不需要签名)。 但是相比每次重新计算整个树来说,明显计算量更小。且我们也需要有一个平衡点,就是这个 fee collector 的交易,可能交易手续费会比较高(用于补足 coinbase tx)。因此这个交易可能会因为激励太大,而导致孤块/重组后有损失。 所以可能只能节约一点,就是数量增加到一定程度后,还是要重新算一下 coinbase tx 的,不能让尾部的 fee collector 的大小太大。
edward tipped:
0.02 USD
1 year ago
edward replied:
@linzheming 联系了Brendan,这是他PPT内容的一个bug,coinbase tx应该在最左侧而不是最右侧。也就是说coinbase tx在最左侧更新,而新加入的tx在最右侧更新。 当然,即使在最左侧,因为coinbase tx更改而引起的merkle树的更新节点也很有限。 另外,还是感叹你给出的方法很妙。
linzheming replied:
coinbase tx 更改,我们需要修改所有左侧的一整条枝干的哈希。但是这样做,我们其实很难马上确定其他交易的默克尔证明的。我还是得算一下需要缓存和刷新的部分分别是多少。 目前来看不是瓶颈问题,但是长期来看肯定可以通过一些方法解决。并且这个对于区块流式传输是有帮助的,也可以减少区块流式传输所需要的数据量或者计算量。