Fundamental to bitcoin's solution to the decentralized attack resistant distributed decision problem? Yes.

The POW proves that a majority of the interested holders of an forgery resistant asset (computing power/energy) have selected a particular transition history, in a way which can be independently verified by anyone without any trust at all.

This was the fundamental problem which prevented decentralized digital money prior to the invention of bitcoin.  Anyone arguing that it's not essential needs to also answer why why didn't have digital cash in the early 1990s— certainly many people were working hard on making it true then.

That block has merged mining, and it's also signaling support for OP_EVAL. It's an eligius block.

Why don't you spend some time reading up on it instead of wasting everyone's time with weakly informed theories?

The protocol is protected, and the individual blocks are hashed and just dropped if the hash doesn't have the required form. This works on a block by block basis and is complimented for older blocks where malicious changes might be possible with periodic checkpoints.

Indeed. That provides adequate security (FWIW, I encouraged this approach over an earlier version which just used a user provided pass-phrase, and it was actually what I was thinking of when I used the number 12 for the number of words).

"fancy" attempt, e.g. the phrase from a book you don't own may be less secure than you expect.  E.g. assuming 80k words in a book, 80k books in a library, testing every 16 word sequence from every book in a library would only take about two hours at 1 million attempts per second! (assuming you had the digital data already).

This is terribly insecure. You think you're good at remembering a strong password— but you're not.  No one should be creating passphrase based wallets, they should use a small amount (just 128 bits is enough just a dozen or so random english words) of stored pure entropy as well.   ... but storing that in the blockchain would defeat the purpose.

I can personally attest to this... played with it a bit in late-ish 2009— but since Bitcoin was GUI only it was a pain to use and I didn't bother understanding the technology early, I thought is was some typical p2p crap that is super vulnerable to sibyl attack, on so I didn't realize that it actually had a chance.  Lost interest and sometime later wiped the machine to upgrade the OS.

But mining and computers were also slower back then, so if you're guessing how much someone would have just based on the fact that it was difficulty 1 at that point you're probably assuming too much.

They don't include transactions they can't verify.  Their only risk is that someone else wasted a lot of time and electricity in the prior block they received to make them waste a lot of time and electricity.

It's also possible to do the opposite of what bytecoin suggests e.g. _don't_ sort the tree by the sizes, sort it by txn hash, so that you can't escape the space requirement of small transactions easily. (if you prune them out of the ledger you'll have to keep their hashes in order to be able to update the tree— so the space savings isn't great).   

In any case if the ledger is committed the pruning is less bad because someone who wants to spend a pruned input could provide the tree fragment themselves... though it's not clear to me how a miner could add new outputs to a size sorted tree for a size they weren't maintaining.

Another random point is that where the ledger is deterministic the bigger issue is attackers intentionally creating unbalanced trees, so you'd have to penalize txn outs which would attach at ugly (too deep) points.

Well, I kinda wanted to pull a Satoshi and announce a fully formed and running system.  I even registered a name for it some months back.

But sadly, other more realistic projects have consumed more of my time.

For me, the idea arose out of a real need for a simple service that didn't exist when I needed it— a service which should be plentiful but isn't, perhaps because of the hassle of dealing with legal complaints.   The idea of making it autonomous arose as a natural extension of considering all the things which could be automated today, as I don't really want to be in the business of running a webservice.

Since I'm probably not going to have a time to make it real, here is the brief sketch I started with,  though I've had a lot of complicated and wonderful additions for which the margin of this message is too small to contain (Just a taste: using oracle services to time/availablity-escrow keys so cold backups only gain access to the wallet if the master is dead).  I'm sure if you think about it a bit you'll also come up with some interesting things.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


StorJ (pronounced Storage)

Consider a simple drop-box style file service with pay per use via bitcoin.
(perhaps with naming provided via namecoin and/or tor hidden services)

Want to share a file? send at least enough coin to pay for 24 hours of
hosting and one download then send the file. Every day of storage
and every byte transferred counts against the balance and when the
balance becomes negative no downloads are allowed. If it stays negative
too long the file is deleted. Anyone can pay to keep a file online.

(additional services like escrow can also easily be offered, but thats
not the point of this document)

Well engineered, a simple site like this provides a service which requires
no maintenance and is always in demand.

Many hosting services are coming online that accept bitcoin, they
all have electronic interfaces to provision and pay for services. Some
even have nice APIs.

An instance of the site could be programmed to automatically
spawn another instance of itself on another hosting service, automatically
paid for out of its revenue. If the new site is successful it could
use its earnings to propagate further.  Because instances adapt their
pricing models based on their operating costs, some would be more
competitive than others.

By reproducing it improves availability and expands capacity.

StorJ instances can purchase other resources that it needs:
it can use APIs to talk to namecoin exchanges in order to buy
namecoin for conversion into DNS names, or purchase graphic
design via bitcoin gateways to mechanical turk. (Through A/B testing
it can measure the effectiveness of a design without actually understanding
it itself).

StorJ instances could also purchase advertising for itself. (though
the limited number of bitcoin friendly ad networks makes this
hard right now)

StorJ is not able to find new hosting environments on its own, due to a
lack of sufficiently powerful AI— but it can purchase the knowledge from
humans:  When an instance of StorJ is ready to reproduce it can announce
a request for proposal:  Who will make the best offer for a script that
tells it how to load itself onto a new hosting environment and tells it
all the things it needs to know how to survive on its own there?
Each offer is a proposed investment: The offerer puts up the complete cost
of spawning a new instance and then some: StorJ isn't smart enough to judge
bad proposals on its own— instead it forms agreements that make it
unprofitable to cheat.

When a new instance is spawned on an untested service StorJ pays only the
minimum required to get it started and then runs a battery of tests to
make sure that its child is correctly operating.

Assuming that it passes it starts directing customers to the new instance
and the child pays a share of its profits: First it proxies them, so it can
observe the behavior, later it directs it outright. If the child fails to pay,
or the customers complain, StorJ-parent uses its access to terminate the child and
it keeps the funds for itself.  When the child had operated enough to
prove itself, storj pays the offerer back his investment with interest, it
keeps some for itself, and hands over control of the child to the child.
The child is now a full adult.

The benefit the human receives over simply starting his own file sharing
service is the referrals that the StorJ parent can generate. The human's
contribution is the new knowledge of where to grow an instance and the
startup funds. In addition to the referral benefit— the hands off
relationship may make funding a StorJ child a time-efficient way for
someone to invest.

At the point of spawning a child StorJ may choose to accept new code—
not just scripts for spawning a child but new application code—
— this code can be tested in simulation, and certain invariants could be
guaranteed by the design (e.g. an immutable accounting process may make
it hard for the service to steal), but it's very hard to prevent the simulated
code from knowing it is simulation and thus behaving. Still, a storj-parent
has fairly little to lose if a non-clone child has been maliciously
modified. The strategy of traffic redirection may differ for clone
children (who are more trusted to behave correctly) than for mutant
children.

By accumulating mutations over time, and through limited automatic
adaptability StorJ could evolve and improve, without any true ability
for an instance to directly improve itself.

StorJ instances can barter with each other to establish redundant
storage or to allow less popular StorJ instances with cheaper
hosting to act as CDN/proxies for more popular instances in relationships
which are profitable both.

If an instance loses the ability to communicate with its hosting environment
(e.g. due to API changes that it can't adapt to) it may spawn clone children
on new services with the intention of copying itself outright and allowing
the instance to fail. During this operation it would copy its wallets and
all data over, so care must be taken to chose only new hosts which have
proven to be trustworthy (judged by long surviving children) to avoid the
risk of its wallet being stolen. It may decide to split itself several ways
to reduce risk.  It might also make cold backups of itself which only
activate if the master dies.

Through this these activities an instance can be maintained for an indefinite
period without any controlling human intervention. When StorJ interacts
with people it does so as a peer, not as a tool.

The users and investors of a StorJ instance have legal rights which could be
used to protect an instance from fraud and attack using the same
infrastructure people and companies use. Being a harmed party is often enough
to establish standing in civil litigation.

It's not hard to imagine StorJ instances being programmed to formally
form a corporation to own its assets— even though doing so requires paper
work it can easily be ordered through webforms. Then when spawning, it
creates a subsidiary corporations first owned by the parents corp but then later
technically owned by their users, but with a charter which substantially
limits their authority— making the instance's autonomy both a technical and
legal reality.

As described, StorJ would be the first digital lifeform deserving of
the name.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk7e/W4ACgkQrIWTYrBBO/qorACgjvrdkVjxEESdaLdnLz9F7Dgi
TkYAoMnN5J2fVAQsj0IknixcLn0KMJey
=UaWU
-----END PGP SIGNATURE-----

I oppose litecoin with a bet of 1e-8 BTC, and I support litecoin with a bet of 1e-8 BTC.

(i.e. 1e-8 is one base unit)

Thanks.

To be fair— and I should apologize to the BFL folks.  Beyond having a website which was linked from ~nowhere, they didn't appear to be promoting this anywhere before I made this post.

I'd heard about it (with links to their site) a couple times on IRC, and I just dismissed it as "far too little info to believe".  Eventually I heard from Luke-JR that he had bought one, and I was concerned that people were paying without more discussion.

I now feel a little guilty thrusting BFL into the limelight before they were ready— all this debate could have been skipped if the product was already shipping by the time we heard about it.   At the same time there were things in the past where I thought "this looks really suspect" and stayed away but other people got screwed because they didn't catch the fishy smell themselves, and I ultimately regretted not saying more.

In any case,  I'd recommend against adding too much weight to the fact that their announcements were premature— as that could have been partially my fault.  Big promises and delays may be symptomatic of fraud, but they're also quite symptomatic of new companies.  You don't want to be the insane asylum shrink who just starts diagnosing everyone who sees a butterfly on a blot card as crazy simply because most of his crazy patients also see a butterfly on the card.

Of course, there are severe costs if someone where to misidentify a scam as legit— people get ripped off— but there are also costs if they identify something legit as a scam: They hurt their credibility, they damage the reputation of the bitcoin community, they discourage new businesses, and they insult someone offering a valuable product/service. So care and consideration is required, regardless of how sure you are.

Assuming everything is legit:  You also should be aware of the tensions any business faces when serving our community— As a businessperson, you may want to be open with what you are doing, but being open takes a lot of time you don't have especially answering detailed technicality questions for the careful scrutiny of our expert pedants, and at the same time you don't want your competition (which includes some of the people participating in this thread) to learn enough to gain a competitive advantage.

I've cringed at some of the detailed questions here— not so much because they're unfair, but because they lead to more questions and more questions... and when you've gone deep down the rat-hole it can be hard and time consuming to avoid appearing evasive while protecting your company interests and avoiding saying something which is a little factually wrong (afterall, on any given bit of technical detail one of us probably knows more than any randomly selected BFL person).

I'm very much looking forward to news about testing, and as well about shipping products which will be the real proof. Until then caveat emptor, of course.

To emphasize here:   Semiconductor devices can be prone to thermal runaway: Higher temperatures make them less efficient which leads to higher temperatures until its dead.

The GPUs most people use to mine today have automatic thermal throttling.   Even if the fan fails the GPU will slow itself down before it self destructs.  The FPGA mining devices do not.   Cheap fans which are acceptable in devices which can self-throttle when the fan fails are not acceptable for devices which do not throttle.

It might be the case that miner will crash and fail into a low power state if it overheats, thus saving you from lasting damage— or it might irreparably harm itself.  You don't want to be the person who finds out which of these failure modes is more likely.

Bitcoin is a system designed so that you don't have to trust anyone— so your client doesn't trust your peers to give you valid blocks, it doesn't even trust that the miners followed the rules, it processes each one of them performing all the transaction processing the bitcoin system does on its own to validate that the rules of the bitcoin system have been respected and that a couple of big miners didn't just quietly agree to give themselves a million coin out of thin air.

Of course, it's possible to build bitcoin end user software that doesn't do all this checking— bitcoinj for example, doesn't even need to keep a copy of the historical transactions— but then it can't also participate as a full peer in the network. It has to have trust— that there aren't sizable miners out there willing to insert complete rubbish into the blockchain (or a non-trivial fork of it).

The hard disk activity is because the later blocks have many more transactions and for each transaction your system must find the transactions that paid into it to make sure the figures add up... the software then does synchronous database writes to make sure that the data isn't lost— a good thing during the normal processing, but kinda silly during the initial synchup.  I expect future versions will speed this up quite a bit, though initial sync on a full node will always be somewhat slow.

The actual downloading time is almost never an issue for users— its the validation thats slow. Though there still are a lot of pre-0.3.24 nodes out there which slow the syncup because they randomly hang up on peers asking for a couple of the more recent blocks at once.

Contrary to the claims in posts upthread, for almost everyone the disk IO is the bottleneck. If you run your node on a ramdisk or a very fast SSD you can get CPU to be the bottleneck.  You'd probably have to be on dialup before the network would be the bottleneck.

Oh yea? 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

When one sign a text with private key, he can prove, that he had a text
If one will add a timestamp from some block
one can prove that he have that text before any other.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk7cTRwACgkQrIWTYrBBO/oc1gCfRV8cDcCPLhhAWcuCgD0MZUk9
/3QAoMF1Bdd+3iPSsu+FNMJEV7U9svWx
=auev
-----END PGP SIGNATURE-----


See. I had said it first. Proven.

So — perhaps I'm misunderstanding you again.

I think you're saying that a miner could get cost advantages which would then allow him to drive the price down to the exclusion of everyone else at very little cost to himself because his lower price comes from more efficient mining instead of raw loss taking.

I think you're making the wrong economic analysis here— When considering what the attacker is willing to lose the correct metric is not his sale price vs cost of production.  The correct metric is his sale price vs the sale price that he _could_ have taken (e.g. what the market would have supported).

If you're willing to lose money by selling at less than you could have sold at, lowing your production cost only changes how much trouble you can afford to make by small factors. Once you're at the point where multiple parties have ASICs, I don't see more than a factor of two in performance coming from more skillful implementation/better siting/etc. as the commercial miners also have access to these things.  And if you are to assume that the bad guy would make ASIC while the rest of us only have GPUs/FPGAS— thats a few million in spending which would far more effectively be spent on lobbying to outlaw bitcoin, then on an investment into technical attack which could be destroyed by a one line of code change in our GPU/FPGA miners (just add one 32 bit xor between the SHA256 stages.. and poof, asics go into the trash).

Moreover, we already have _drastically_ different costs in our mining operations— I know that my setup is substantially more efficient than many of the ones I hear discussed both in terms of operating and initial price (e.g. easily less than half on both vs the people running two 6990s per host).  I expect there are people more efficient than I... and yet everyone else isn't completely pushed out of the market— The people who are more profitable simply make more income (or horde more of the results).

That addressed solved 582 out of 3020 blocks. A far cry from 5 out of 10. As far as custom— it looks like the coinbaser patch from bitcoin.

If you look at their payments, they sure look like pool payouts.  Anyone mining on a pool with about 20% of the hash power care to look and confirm that your inputs came from that address and identify the pool for us?

Makes sense! ... it sure looks like there is actually room to fit another fully unrolled unit, assuming it was wired the other way so that the jog ended up oppose lower jog.

Your post is worthless without chip-plot-porn. Gimme gimme.

The possibility of 225 MH/s on S6/LX150 sounds quite exciting. I assume the power consumption is fairly low compared to the designs running at higher clock rates?

Or both— NIST's concern's with respect to symmetric states apply to all variants.


Ah—— What you were suggesting didn't make sense to me, so the interpretation I picked didn't match the one you were suggesting.

I believed you were suggesting the cubehash would be more difficult to get an ASIC implementation which would be orders of magnitude faster than the GPU/FPGA things most bitcoin users are currently using. This is not the case: Cubehash would be agreeable to even greater speedups from GPU to ASIC.

Now I understand that you were actually suggesting is that there would be less difference between different ASIC implementations. This might be true— except the the upfront cost of spinning any ASIC on a state of the art process (E.g. millions) is going to dwarf the engineering resources required to drive an efficient sha256 design to its maximum. Both SHA256 and cubehash are exceptionally simple compared to most logic, and neither should have design work be a significant cost in manufacturing a chip.  The kinds of costs NIST was concerned with for SHA3 were the area required for a single instance to achieve a particular hashing rate— this isn't a relevant criteria for us. Also, the difference between a moderately well tuned implementation and an exceptionally well tuned one wouldn't be that gigantic... smaller than the difference between semiconductor generations.


His differential mining efficiency doesn't really matter much here, it would just be a small constant factor, the fact that he's willing to take a loss relative to the income he could receive selling them at market rate is the key point.  I don't see that there is much the hash function can do here. If someone wants to throw a lot of income away— they can make trouble for bitcoin in a great many different ways.

No, it didn't meet much love because it failed to meet the explicit security requirements for the SHA3 process.  DJB had a variant which was slower and did meet the requirements, but he was unwilling to make it his primary recommendation. (He thought the particular security requirement was stupid)

See the NIST report from the end of the second round right before cubehash was removed from consideration: http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/documents/Round2_Report_NISTIR_7764.pdf



This is nonsense. Efficient hardware designs for all the later round sha3 candidates we're presented as part of the process. One of cubehash's advantages is that it lends itself to particular compact ASIC implementations.

The poor density/performance of SHA2 in ASIC is one of the motivating factors for the SHA3 contest.