TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Bitcoin block propagation with IBLT, Part I

49 点作者 martinkallstrom超过 9 年前

3 条评论

kang超过 9 年前
The problem statement is not so simple; one one hand there is incentive for the miner to keep the block small so that it propagates the network faster but that is looking at immediate profit, however, on the other hand, Peter Todd has shown[1] in the bitcoin-dev mailinglist that actually &quot;increasing&quot; the blocksize and even withholding it for some time significantly increases profit in the near long term.<p>Now, even ignoring this, if we assume the problem statement just as what the author describes, there are problems with his approach. Firstly, big pools have said that they operate at a loss and their aim is not to earn profit from mining but by providing value-added services like &#x27;guaranteed tx confirmation&#x27;, which big pools can. Secondly, and technically, this only works if data set is low so as to keep collision low [2]. Beyond a certain point there are many false positives and worst case all transactions might be needed to sent anyways.<p>So although this is not worse than the current status, but certainly could end up not even being useful.<p>[1] <a href="http:&#x2F;&#x2F;www.mail-archive.com&#x2F;bitcoin-development@lists.sourceforge.net&#x2F;msg03200.html" rel="nofollow">http:&#x2F;&#x2F;www.mail-archive.com&#x2F;bitcoin-development@lists.source...</a> [2] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Bloom_filter#Interesting_properties" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Bloom_filter#Interesting_prope...</a>
评论 #10374278 未加载
评论 #10374777 未加载
placeybordeaux超过 9 年前
The abstract problem is there is a set of objects and all peers have access to some subset of them. You want to communicated an ordered list of them plus some arbitrary data (your winning hash) to as many peers in as little data as possible.<p>It seems to me that the best solution is to have a well agreed upon function that keeps them in an ordered state and simply keep track of what transactions your neighbors know about, the information should largely already be there due to the fact that the transactions are dissiminated by a gossip protocol in the first place.
kanzure超过 9 年前
Here is where IBLT was specified:<p><a href="https:&#x2F;&#x2F;gist.github.com&#x2F;gavinandresen&#x2F;e20c3b5a1d4b97f79ac2" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;gavinandresen&#x2F;e20c3b5a1d4b97f79ac2</a><p>More:<p><a href="http:&#x2F;&#x2F;lists.linuxfoundation.org&#x2F;pipermail&#x2F;bitcoin-dev&#x2F;2015-May&#x2F;008000.html" rel="nofollow">http:&#x2F;&#x2F;lists.linuxfoundation.org&#x2F;pipermail&#x2F;bitcoin-dev&#x2F;2015-...</a>