This is one of the most complicated parts of Bitcoin imho. The data that is signed is a double-SHA256 hash of a specially serialized version of the transaction.

First, the transaction is copied. The input being signed is replaced with the scriptPubKey of the corresponding txout.

With the default hashType SIGHASH_ALL, we're done now. But for the other hashTypes SIGHASH_NONE and SIGHASH_SINGLE as well as the SIGHASH_ANYONECANPAY flag, some more steps are needed. See the function SignatureHash in script.cpp for details.

After that, the transaction is serialized and the hashType is appended as a single byte, followed by three zero bytes, e.g. 01000000.

Then Bitcoin calculates the double SHA256 of that and signs the resulting hash.

I implemented this twice, once in pure JavaScript, once in Node.js. Both times it was a royal pain in the ***.

I wanted to share some thoughts about how Webcoin is going to handle DWs. I'll use the same symbols as TierNolan.

First of all, I don't see the need for a seed. Since the seed has to be stored with the private key anyway, you might as well regard it as part of the private key.

Next, the master private key should have a full 256-bits of entropy. So we use a random number 0 < a < 2²⁵⁶. Yes, it's a pain to type. In practice you'd normally use more convenient ways to transfer DWs, such as USB sticks, QR codes, etc.

(However, if your house just burnt down and you lost every backup but the printed hardcopy at your safety deposit box, I don't think having to type a very long password is going to concern you too much.)

Here is an example of a 256-bit number using base58 encoding:

"6QPCJCRhPSVoKL4hhLoqRuBEk4VYzAFMAC1GwQ7JbSR4"

In reality we'll also add a checksum and a version byte, similar to a Bitcoin address.

In our version, there is no seed, so we've been working with v(t, n) instead of v(n, t, s).

t ... type is included only for future use. Currently it is a zero-length string, i.e. it is omitted.
n ... serial is a 64 bit unsigned integer (LE).

So a new keypair b, B is generated as:

b = a + SHA256(A t n)
B = A + SHA256(A t n)*G

A is an ECPoint encoded using standard non-compressed form (0x04 x y)

To generate a new public key for the wallet, you need to know A, t and the next serial number to use.
To spend the coins on any of the addresses, you need to know a, t and the serial number.

During normal use, we assume that we have access to a metadata storage system. The metadata storage is retrievable using an access key SHA256(A "access"). It's contents are unencrypted, symmetrically encrypted or asymmetrically encrypted depending on the application. For example, a merchant server whose only job is generating addresses would encrypt metadata for those transactions using a public key and the wallet would retrieve it using the corresponding private key. That way, if the merchant server is compromised, privacy for previous transactions is still guaranteed.

If the metadata is lost for any reason, the user can use a recovery tool to get their coins back. The recovery tool needs a full database of unspent outputs in the block chain and will simply generate public keys using sequential serial numbers using the method above. Whenever it finds coins it will add an entry to a new metadata array.

Note: Using t will make coin recovery more difficult, because the recovery tool will have to a) know all values for t and b) separately scan them all. That's why we're more interested in keeping t an empty string for all normal use cases and using the metadata to synchronize what the next available serial number is.

The maximum number of addresses for one wallet is 2⁶⁴ or 18,446,744,073,709,551,616 (for each t).


Correct. I want to add one more: As long as the master public key A is secret, nobody can break the privacy of the other addresses.

Would this sha256 function be safe for us to use inside Webcoin? Or is it "mining-specific" in some fashion? I can't see how it would be, just making sure.

Also, do you want to have a go at optimizing Webcoin's JavaScript ECDSA stuff as well? It's the bottleneck in Webcoin at the moment. Any speedup to the elliptic curve point multiplication or big integer math would be a godsend.

It's not in production and won't be for a while. Right now I'm focusing on my main project Webcoin, due to the fact that wallet security is such a prominent and urgent subject at the moment.

I also lost access to the marketing wallet (7000 BTC), despite having three copies (one in a VirtualBox, one on Truecrypt/Dropbox, one somewhere else). Details on the loss are in the #bitcoin-dev chatlogs if you care to search. Anyway, this was extremely frustrating and another reason to focus on better wallet security.

Das war der Stille-Post-Effekt - Herr Jansky hat mich ja im Interview noch korrekt vorgestellt: "Chefentwickler von BitcoinJS, JS steht für JavaScript" - aber irgendwo in der Kette hat dann einer das JS vergessen. Die Pressemitteilung war ebenfalls inkorrekt, ich hab denen schon diesbezüglich gemailt und werde wegen der YouTube-Beschreibung nochmal ne Mail schicken.

No reason why different clients have to be incompatible. The client I'm developing, Webcoin, is a normal Bitcoin client, but it will protect your coins in case the normal Bitcoin client is found to have a vulnerability. BitcoinJ and Spesmilo are examples as well.

If there are entirely new currencies, they should have some significant change compared to Bitcoin. Otherwise why should anyone invest time in supporting/using them?

Kurzes Interview beim Zukunftskongress 2b AHEAD in Braunschweig:

http://www.youtube.com/watch?v=1eVwIzBYQMw
http://www.youtube.com/watch?v=3MJoF6Q5-HA
http://www.youtube.com/watch?v=XBLnqnL75_M

Bin einer von drei Gästen im "Extremistenpanel" - toller Name, naja. Die Resonanz nach dem Interview war sehr gut und habe einigen Leuten Bitcoin hinterher nochmal genauer erklären müssen. Darunter auch der Chef einer kleineren Bank, der meinte sie würden schon mit digitalen Währungen handeln und können sich durchaus vorstellen Bitcoin auch aufzunehmen. Alles in allem ein interessanter Anlass und ich hoffe ich habe Bitcoin ordentlich vertreten.

You say that the difficulty for each maturity is determined "like difficulty is handled right now" i.e. self-adjusting so generation remains constant in terms of units generated per time period. But if generation of bonds of each maturity is constant, then the last sentence in the quote above makes no sense, the relative amount of each bond issued couldn't fluctuate.

You can either let relative hashing power determine the difficulty for each bond type or the amount of each bond type, but not both.

To do what I think you want, you'd need to find out what people are paying for those bonds. Then you would have enough information to adjust the difficulty such that the "(present value at market) per (unit of work)" is the same for all maturities. The problem is you cannot find out easily and securely how much the bonds are trading for - at least it would get very complex at that point.

Let me know if I misunderstood your proposal.

I've sold Bitcoin options and made good money with it. You can sell mining contracts, futures, etc. for Bitcoin just like silver or gold or any other commodity. There doesn't need to be any fancy mechanism in the software itself.  :-)

Bitcoin bunker? Very cool project. Can you post a BTC address for donations?

Webcoin will do this by default. If you're a techie and you're interested in the details, check our specification:

http://bitcoinjs.org/specs/wallet/1.0/draft/wallet-api.html

Aside from bug-fixing that's the last feature we need to implement before we can launch.

For more on the project http://bitcoinjs.org/

Don't think so, different style. This one is a YouTube-focused scam, aside from Bitcoin, they're also targeting ShareCash users and probably others. (They also have spam bots that post comments on the videos and vote them up to make it look more realistic.)

Also, the malware is hosted on fileups.net instead of github.

Someone just posted a comment on the WeUseCoins video saying they had a "coin generator" on their channel. If you went to their channel you found a link to a downloadable piece of software. I don't know if this software would try to steal your wallet or just contain a general trojan/malware, but I thought I'd mention it.

I've since removed the comment, blocked the user from the channel and reported the video with the link as scam/fraud. YouTube removed the video immediately. All this happened within a few seconds of the comment being posted (I get email notifications about comments on the video.)

If somebody wants to analyze the malware, PM me and I'll get you the link to the channel and the download link.

We are going to see more and better Bitcoin-related malware, so be wary about downloads of any kind.

Since nobody posted a link to this tweet yet - seems relevant: https://twitter.com/#!/MikePFrank/status/78409140699017216

Note that I have no idea how the terms VLSI and ASIC relate to each other, only that both are talking about chips. 

If someone with a gold reserve starts a currency they would probably want to get something out of that deal. If it's somebody private they probably want to get revenue out of it and if it's a government they'll want control/regulatory powers.

In either case, it'll be a very different currency than Bitcoin.

I don't think doubling the natural fee will be anywhere near enough to create the necessary hashing rate. My guess for a sensible hashing budget to ensure security would be somewhere around two hundred times the transaction fees. Remember, we are assuming a world where transaction fees are no longer dictated by the client developers. They would be much lower than what they are now - an ECDSA verification does not cost 0.005 BTC, not even close.

The point is, arbitrary rules like this will result in hashing revenue that is too high (wasting money, electricity, etc.) or too low.

There are lots of impossible to predict factors such as the likelihood of government intervention that algorithms can't predict or incorporate. Therefore they will need changing from time to time. Miners will seek to influence this process. Gavin might be all idealistic now, but opinions change, invitations to exclusive sporting events get made, you know how it is. Certainly a little bit higher security wouldn't hurt, would it? There have been some double spends recently, haven't there? I mean we're not talking about a major change here, we'll just tweak this knob a little. See? This wasn't so bad was it!

I'm not sure if the lobbying of Bitcoin developers can be prevented in the long run, but in the short run let's at least not give ourselves outright control over miner income.

I'll use the rest of this post to explain why I think that users will be able to solve this problem quite efficiently themselves, without developers having to intervene at all.



This is exactly why I suggested an insurance model. It covers these differences - if you are a merchant who has a low rate of double spends because your customers are all very honest, you can get lower insurance premiums. If you're sending money to grandma, you don't need to pay insurance at all.



Sorry, but you're looking at it backwards. The security is additive. The chain security is the sum of what everyone using it is willing to spend on security. So if you send money to your grandma using Bitcoin and you don't get insurance, you don't contribute to the security level, but you don't detract from it either. (Note that even if you don't pay insurance you still carry the cost of hashing, because you still carry the risk of your transaction not getting confirmed. In other words, you benefit from insurance company's attempts at improving security. But, the risk you carry is a cost worth roughly¹ what you would've paid for insurance so it's not like you're leeching of of anybody or whatever.)

If someone transfers billions of dollars worth of coins at a time where Bitcoin's security is fairly low, he will have to pay high premiums. The insurance firm will try and figure out if it's better to raise the hashing rate or just shoulder a higher risk of an attack happening. If the risk is too great for whatever reason to use Bitcoin for such a transfer, the premium will be prohibitive and the transfer won't take place. If you think that's a bad thing and you advocate some minimum fee or other artificial way of raising the hashing level - what you're essentially advocating is my grandma and me subsidizing other people who do other kinds of transactions. Personally I think all types of transactions will be easily insurable in practice, but who knows. It's better to have a system where some extreme edge case transactions are too risky and uninsurable than a system where everyone else has to carry the cost for the riskiest transactions.

In a world with Bitcoin transaction insurance, the amount of money available for hashing at any given time is the total amount of money being transferred with insurance. In the short run, insurance companies will be willing to spend up to 100% of a transaction's amount in order to get it confirmed. For example they may do a contract with a render farm or super computing center to provide extra hashing in case of a large-scale surprise attack. They will contract with each other to coordinate such efforts - because that means lower risk from large attacks and that means lower costs.

A long-term attack like a government trying to shut Bitcoin down would cause them to raise premiums and at that point it's a matter of who is willing to spend more money overall: the global Bitcoin user base or the attacker. However, "more hashing" is not always the best defense. Imagine the US government attacking Bitcoin. Insurance companies could hire lobbying firms to stop that practice. They could advertise to get public support. They could help mobilize and fund Bitcoin's grassroots supporters and stakeholders.

In the event of a private company like a competing payment processor attacking Bitcoin, they might seek help from law enforcement. Hashing for the purpose of blocking all transactions or otherwise interfering with Bitcoin would likely be considered criminal hacking in most countries. Even if legal prosecution doesn't succeed, such practices if exposed would do tremendous damage to a company's image. So if you can find out who recently bought ten thousand high performance graphics cards, they would be in a lot of trouble.

Insurance is the tried and true way of dealing with risk. Whether it's a Bitcoin transaction or a money truck, if you want to be covered in case it doesn't make it, get insured. And the nice thing with Bitcoin is that money in transfer can't actually be stolen, only stopped/reversed. So Bitcoin transfers between trusted parties at least will be a lot cheaper to insure than any money truck.

And once again, I'm not advocating for doing anything. All I'm saying is that Satoshi's design will hold up as is. Regulation of the hashing level does not have to and SHOULD NOT be included in the protocol. Because doing so would be much less flexible and fair than letting people create suitable institutions themselves.

---

¹ Reality is a bit messy - the person getting insurance would pay a little bit more than the pure risk due to administrative overhead. But as the existance of other insurance companies proves, people are willing to pay that little bit extra in order to have certainty. It is likely that many transactions, if not most, would be insured. Convenience goes a long way.

There is no "50% majority algorithm".

Bitcoin considers the longest block chain valid. So requiring anything other than simple majority would mean something like waiting for competing chain forks to reach a significantly different length before accepting either one. This is problematic because a single side chain block can make the main chain untrusted for 20 blocks (using the 95% case as an example).

Another way to put it: Requiring 95% acceptance essentially means that Bitcoin can be shut down with only 5% hashing power (because the rest of the network will no longer be able to achieve a 95% consensus).

All mining is "offline" - "retrieving the puzzle and submit[ting] the solution if found" is exactly what all miners do. You can mine without including transactions, in which case you won't have to verify anything, but you also won't get any transaction fees. Users will offer transactions fees high enough to cover all costs involved in verifying transactions in order to get their transactions confirmed.



Anybody who wants to verify a transaction needs a full copy of the block chain since the oldest output used in that transaction. So at least miners will always have a copy of the chain. They will also want the public to be able to access this data, otherwise the Bitcoins they make while mining could not be spent anywhere.

Other parties like merchants, service providers, law enforcement, academia, NGOs, websites, etc. will also maintain full copies for various reasons.



Others will be able to answer this better, but from what I understand ECDSA verification is expected to be the bottleneck, not network performance.

Haha, genial. Ich hatte Jörg im Dezember von Bitcoin erzählt, hatte aber keine Ahnung, dass er plant es in seiner Sendung zu erwähnen. 

(Falls jemand denkt ich hätte diese Info lieber für mich behalten sollen: Die Bekanntschaft kann sowieso jeder übers Schweizer Handelsregister rausfinden - besser also so, als wenn nachher jemand sagt das wär Vetternwirtschaft. )

The official client is. It also doesn't relay them. Meaning you need both a miner/pool like Luke's that accepts them as well as a direct connection there.