Only the private key holder of the tx output can create a new tx.  There is no mechanism to "copy the outputs as a new transactions to the head" and then verify off that.

Well you are abstracting away the entire problem.  It is like saying how can we get into space and your answer is you keep going up until you are there.

Rereading your OP my guess is you don't understand how Bitcoin works (what is a transaction?  how does it work?  what are outputs?  what is the UXTO?  how can we verify that any given output is valid?).

If I "sent" you coins and you didn't have the block which contained the transaction which contained that output how would you validate the input is valid and not just some nonsense I sent you because I know you have no way of validating?

Better yet how do the new nodes verify that the agreement has been reached and that agreement is valid.

To OP, the reality is most nodes in the future will be SPV.  The storage requirements are maybe 1% of that of a full node.   Eventually even most "full nodes" will be storing only a pruned copy of the db.  Today that means a 80%+ reduction in storage requirements and that will only improve in time.   Some nodes (maybe call them archive nodes to distinguish from full nodes) will need a full copy of the blockchain and for them the cost will be worth it.  If you are a major exchange and are making $1B a month in profit (and you would if Bitcoin is so huge it has higher tx volume them VISA) do you think it might be worth it to pay $1,000 a year in additional storage cost to add some drives to the SAN?  I think it might be.

  It isn't that complex although when I am not working 60 hours a week I have been experimenting with alternate methods of passing infromation between the offline and online computers.   One method involves using animated QR codes and web cam, the other involves transfering it as an encrypted sound stream using mic-in port (same method square uses for their card reader dongle). 

Paper can be "hacked" onsite as well. 

  Your grandma won't be using a laptop.  What can be done with a laptop can later be done with a dedicated hardware wallet which is mass produced at a nominal cost and can provide her a level of security she could never possibly hope to achieve if she keeps clicking on lolz_cats.exe attachments.

Those are all used in Bitcoin however none of them are encryption methods.  Hashing algorithms, digital signature algorithms, and encryption algorithms are all cryptography. 

There is actually no encryption used in the Bitcoin protocol although many wallets do employ encryption (most commonly AES) to protect the keys from being stolen.

As for how do they all fit together ... that is a long topic and I have drunk too much port.  Start looking at the bitcoin wiki.

For general information on SHA-256, RIPEMD-160, and ECDSA (or ECC in general) wikipedia will give you some basic background information.

You probably have read a lot of things online which are completely untrue.  Bitcoins can't be counterfeited.  Every node of the network is aware of every confirmed transaction and all transactions can be traced back to their minting.  Any coin created from thin air (outside of the authorized and limited amount in block creation subsidy) would be immediately recognizable as invalid.  

Bitcoin can be stolen, lost, double spent (under some conditions), and even mined out of existence but they can't be counterfeited.

BitSimple does that.  There is on customer wallet managed by BitSimple.  To sell you send coins to BitSimple and the trade executes immediately (zero confirmations to lock in a price), to buy you designate a receiving address when you wire the funds.  Then again Tangible Cryptography has never lost a single satoshi of user funds so we might be on to something.

You keep your coins in your wallet all the time and you can still have instant liquidity.

I think you owe Danny some tuition for the Bitcoin 101 course.

One small thing to add to all that good information is transactions are never "spent".  Outputs are spent.  A transaction can contain one or more outputs.  Each can be spent independently.  An output is spent when it is referenced in the input of a future transaction.   The input of all transactions (with one exception) references a specific unspent output.

into the malware infected computer and the attacker steals them the second the system becomes aware of the private key.

It might be overkill for a couple bitcoins but if you are talking hundreds or thousands it is well worth the money to have an secure dedicated laptop to perform offline signing.  The private keys never touch a computer connected to the internet .... ever.  Not just in storage but also in use.

This doesn't mean you can't also have paper backup as a backup to the offline signing device.


The keys NEVER leave cold storage.  The only thing copied to the hot wallet is the complete digitally signed transaction.  The hot wallet could be a cesspool of infection and the attacker would get nothing that isn't already public information anyways.

I will save you some time.  That is a completely false assumption.  Don't feel bad it has been made by people who should know better over and over throughout history.  DRM is an example of a secret hidden in the software (or media) such that the user can't gain access to the secret even though they have access to the media or software.  No form of DRM running on an open system has survived cryptoanlysis over an extended period of time.  To date the reward for breaking DRM has been the ability to duplicate a game or movie, here you are talking about increasing the reward to be stealing money.  I would put the over/under on timeframe to being broken wide open at a week (maybe a month if the implementation is particularly novel).

If you are talking about dedicated hardware devices the attack becomes more difficulty but not impossible.  Private keys have been recovered from smart card chips and even FIPS rated hardware security modules.  Once again if the system becomes widespread the reward could mean potentially millions of billions of stolen wealth so "difficult" is simply not good enough.  Furthermore those systems wouldn't be provably secure and would be highly centralized.

If the user has access to the software and the software has the secret the user has (or will eventually gain) access to the secret.  If that were not true the rate of software piracy would be approaching ~0% by now.  People have been working on this "solution" for decades.

Since this is an X-Y problem it is very likely novel use of cryptography could be used to achieve the goals you state but not through the method you describe.

I think you may be on to something here!  You could prove the transfer of value using the secret number to sign a receipt of sorts, instead of revealing it.  That way others can verify the receipt, yet can't produce forgeries.   The receipt would then give the receiver irrefutable proof that funds have been transferred and anyone could verify that transfer.  The main obstacle that has thwarted other systems in the past is that a person could sign two different receipts spending the same funds twice.  If only someone could invent a network, maybe consisting of a large number of anonymous peers, secured by a method of proof that would finally solve this two-spend problem.  Then we would have a system which allowed any individual to engage in commerce with any other individual without the need for a central authority.  The days of having wealth stolen while under the control of a third party would finally be over.

Well we can hope someday someone will invent it.  Whoever he ends up being, I would like to shake his hand, or maybe buy him a beer with these "unforgeable irrefutable receipts of wealth".  

Or you could stop using sites which put the entire risk of failure on the user.  Uninsured user deposits makes users non-profiting investors.    If the site does well the true owners profit, if the site does bad the depositors lose everything.

How about not having user deposits?  BitSimple never holds bitcoins owned by users. Users hold funds in their own wallet and can sell them with zero confirmations by transferring them to BitSimple.  Purchased coins are likewise sent directly to an address designated by the user.

If we get hacked it is investors funds that are lost; not surprisingly that makes us very motivated to ensure we aren't hacked.  It also makes running a hidden fractional reserve system impossible as we are using our own capital.  Tangible Cryptography (parent of BitSimple) which has been around since 2011, and has not lost a single satoshi, very few Bitcoin related companies can make similar claims.

So if law enforcement isn't enforcing existing laws or investigating existing crimes why would you think that more regulation would change anything.

Summarized:
The cops are not enforcing the laws, so the solution is to pass more laws.

FYPFY.

Nothing wrong with Java running server side.  The security hell that is java applets needs to die.  I personally don't install java client side not because it is any direct risk but out of fear that some browser exploit will enable java applet access.  If java applets were killed off an no longer supported by modern browsers I would have no issue with java client side either.  Most financial institutions and large enterprises use java server side. 

The issue isn't so much PHP as the way it was used.  As a side note, you can shoot of your own foot with any programming language, PHP just makes it easier than others.  I would use Python over PHP because dynamic typing and implicit (warningless) conversion between types just makes it to easy to create bugs which only occur run time.  Combine that with no test driven development and you got a recipe for hard to identify bugs.

Someone up thread said testing, testing, and testing.  That doesn't mean let me try to manually "test the hell out of this" it means things like unit testing, code coverage, mocking, automated test validation in build process, etc.  That is impossible with the code as written.  The code as written is untestable, unmaintainable, and undocumented.  Everything is a bunch of static methods, magic constants spread throughout, SQL code interspersed with business logic, mixed with formatting.  The few places where a constant should be used they decided to use a literal 100000000 for conversion from satoshi to Bitcoins.  Money values are handled as floats.  Everything is tightly coupled and poorly documented so if Mark ever did bring on additional programmers that would just be a timebomb waiting to go off.  You can get god's gift to programming but if other "lesser" programmers can make fatal mistakes with your code because it is fragile ... it is bad code.

CNN was a victim of the known sentence malleability bug.

Miners discarding the valid blocks of miners who refuse to engage in the unethical blocking of wealth based on no due process is extortion and tantamount to theft of the block reward.

Seconded.  I move that the blacklist should contain no addresses and be forever closed to new addresses.   Situation resolved.

Theft for the greater good?  Decentralized is too scary, bad people might do bad stuff so we should instead facilitate absolute control by a cartel who is almost certainly to end up doing bad stuff.  


Consensus obviously doesn't mean what you think it means.  51% is not a consensus, it is a majority.  Deciding who has the money based on majority rule is a terrible idea.  The point is you have no possibility of a consensus so instead you would force your will upon the minority (potentially a very large minority) by extorting their valid mining reward to compel them to act against their own better judgement.