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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Proof of Existence: Storing Hashed Files in the Bitcoin Block Chain

60 点作者 CrunchyJams超过 11 年前

9 条评论

icebraining超过 11 年前
Discussion from yesterday&#x27;s submission, with 75 comments: <a href="https://news.ycombinator.com/item?id=6809929" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6809929</a>
rdtsc超过 11 年前
This makes me think of another thing I was wondering about -- can some entity that doesn&#x27;t like having Bitcoin around for whatever reason, DDoS it by filling it with meaningless transactions.<p>Maybe just setting up 100 addresses and constantly transferring small payments between them, filling the transaction history with garbage. Is that possible, and is there any protection against that?
评论 #6819561 未加载
评论 #6819783 未加载
评论 #6819569 未加载
mathretardthrow超过 11 年前
There is absolutely no proof that one-way functions exist: therefore this is not a &#x27;proof&#x27; of existence of files at a certain date.* It is just a strong indication of it.<p>* that is, at some future date (or secretly, today) an algorithm could be discovered breaking the one-way function used to generate these hashes. Then a collision could be found, perhaps with chosen-prefix. Meaning an arbitrary file could be suffixed so that it looks as though that is what was hashed today. In the past, many hash algorithms thought to be strong were weakened in this way.
drakaal超过 11 年前
Adding lots of data to the transaction logs is one easy DDoS. Do so many transactions that the logs get to be larger than fit on most systems. With multiple Gigs of data already required, if someone was evil they could up the volume and keep people out of the game by making sure that that there were over a terabyte of transaction logs. Most machines won&#x27;t have that kind of storage and would &quot;fall off&quot; the network.<p>Patient0 mentioned before I got to post this, the other attack I know would work. Destroying tokens. But it is a bit more complex than he mentions, but you can actually generate ECDSA key&#x27;s that will work for one transaction, and then never again. A one time spend token that then self destructs for the person you paid.<p>I haven&#x27;t been able to build anything that would work for two transactions. Which would be the most useful since you&#x27;d have a delayed &quot;poison coin&quot; but I don&#x27;t see any reason it isn&#x27;t computationally possible.
评论 #6819935 未加载
评论 #6820383 未加载
notacoward超过 11 年前
I&#x27;m not exactly a big Bitcoin booster, but I love the way techniques and structures developed for it are being adapted to uses like this.<p>Given that this seems very similar to el33th4xor&#x27;s Virtual Notary, how would one distinguish between the strengths or use cases of the two?<p><a href="http://hackingdistributed.com/2013/06/20/virtual-notary-intro/" rel="nofollow">http:&#x2F;&#x2F;hackingdistributed.com&#x2F;2013&#x2F;06&#x2F;20&#x2F;virtual-notary-intr...</a>
评论 #6819766 未加载
评论 #6819835 未加载
Patient0超过 11 年前
&quot;This is why the bitcoins sent in this special transaction are unspendable, as the addresses are being generated from the document&#x27;s hash fragments instead of from a private ECDSA key.&quot;<p>I hadn&#x27;t realised before that this means that you can provably &quot;destroy&quot; bitcoins. That is, you can &quot;prove&quot; that a certain bitcoin amount will never be spent again by anyone including yourself...
评论 #6819602 未加载
评论 #6819640 未加载
daviddoran超过 11 年前
I&#x27;ve been interested in the benefits of something like <a href="http://www.guardtime.com/" rel="nofollow">http:&#x2F;&#x2F;www.guardtime.com&#x2F;</a> for a while. Using a distributed network like Bitcoin seems perfect.
Thiz超过 11 年前
Can a coin survive without a ledger? I rather see a coin with proof-of-exchange without a ton-of-gigs blockchain at all.
评论 #6819758 未加载
JulianMorrison超过 11 年前
Bitcoin would be an awesome &quot;dead drop&quot; for untraceable communication of small data.
评论 #6819822 未加载
评论 #6819825 未加载
评论 #6819860 未加载