Emulation of Hash-Time-Locked Contracts of the Lightning network by a trusted, but publically auditable escrow service
http://cornwarecjp.github.io/amiko-pay/doc/lightning_emulation.pdf

The Lightning network is a design for a decentralized, scalable network that allows for fast, cheap Bitcoin transactions without requiring trusted third parties. However, it requires the presence of new functionality in Bitcoin: without this new functionality, the Lightning network can not exist. So, in order to make the Lightning network a reality, the Bitcoin community must be convinced to accept this new functionality. While none of this new functionality is known to have any controversial characteristics, some of it has, so far, no use case outside the Lightning network.

Since any new functionality makes Bitcoin more complex, and more complex systems have more places where vulnerabilities can exist, the Bitcoin community might be reluctant to accept new functionality, unless convincing evidence is provided about the value of the new functionality. However, so far, the Lightning network only exists on paper, and has not been demonstrated to be useful in real-life conditions. This creates a catch-22 situation: in order to convince the Bitcoin community, we would like to make a working implementation of the Lightning network, but in order to do that, we need to convince the Bitcoin community to include the required functionality.

There are a couple of ways to escape this catch-22 situation:

• The Bitcoin community might accept the required functionality, even without a working Lightning network.
• It is possible to demonstrate the Lightning network on an alt-coin (possibly one specifically designed for this purpose), or on a side-chain, once side-chains are realized.
• It might be possible to emulate the missing functionality, with some loss of desirable properties, using only the already existing functionality of Bitcoin. This would allow Bitcoin users to become familiar with Lightning-like technology, while simultaneously increasing the pressure to "fix" the loss of desirable properties by including the missing functionality in Bitcoin.

This paper describes a design that follows the third approach. The "no trusted third parties" requirement is relaxed, by introducing a partially trusted escrow party, which can be audited by arbitrary third parties. The design is such that, after the missing functionality is introduced to Bitcoin, the migration to a full- featured Lightning network can happen gradually: pairs of neighboring nodes are free to choose when they upgrade their link to a real Lightning link, and during the migration period, transactions can be routed through both old-style and new-style channels (in any order).

I'm thinking of implementing this in Amiko Pay.

I have reasons for reconsidering the license of my Amiko Pay software, and because of that, I stumbled upon the Affero General Public License. This free software license requires service providers (typically, the operators of websites) to publish the source code of the service they're running.

I want to ask you, members of the Bitcoin community, how you feel about using this kind of license for Bitcoin-related software. It has the potential to push an entire ecosystem to become open-source-only. This would have interesting consequences: for instance, if an exchange uses AGPL-licensed software, you can easily request their source code and start a competing exchange with exactly the same set of features. It would also, at least in theory, provide some transparency about e.g. how your data is handled in a web service.

The obvious downside would be that people / organizations who don't want to share their code have more difficulty entering the ecosystem; this could create a barrier for adoption. Maybe this is a trade-off between achieving fast adoption of the monetary freedom provided by Bitcoin, and achieving software freedom.

I believe the Bitcoin Core software has a MIT-style license, so it opts for maximum adoption of the software, at the cost that some adopters might keep their software closed-source. Is there consensus that this is the best model?

I know I'm not the first to suggest using a Ripple-style system as a de-centralized currency exchange. My own focus in developing Amiko Pay has always been to have a fast, scalable, low-trust, privacy-friendly payment system, and honestly, that's already so ambitious that the idea of making a multi-currency system has had a low priority for me. Also, the features of crypto-currencies like Bitcoin are necessary to make Amiko Pay low-trust in a way that can not be achieved with fiat currencies.

Still, the idea that Amiko Pay can be used for multiple currencies and for decentralized currency exchange continued singing around in me, especially since other Ripple-style systems also managed to do this. A couple of weeks ago, I realized it's actually quite simple to achieve, by using colored coins.

The idea is that people can form Amiko networks for different colored coins, and for non-colored coins. People who wish to exchange one for the other simply participate as gateways between two of such networks. An exchange can take place across both networks as a single Amiko transaction, which is either fully committed or fully rolled back, so it's equally low-trust as normal Amiko transactions.

Of course, people still need to trust the issuer of the colored coins, but that trust can not be avoided with fiat currencies. The good thing is that the colored coin issuer has nothing to do with managing transactions or providing exchange rate / trading information, so it has significantly less power than e.g. a MtGox-style Bitcoin exchange. In fact, different people don't need to trust the same issuer, as long as there are enough people in the network willing to provide 1:1 exchange between colored coins of different issuers. For reasonably reliable issuers, this should not be a problem.

This might have some legal implications though. Here in the Netherlands, like in some other countries, Bitcoin is not considered to be money, so AML/KYC laws do not apply. The implication is that it's perfectly fine for individuals to deploy Bitcoin-only Amiko Pay. However, I can imagine that colored coins which represent fiat currencies are in fact considered to be money. To be on the safe side, I don't think I'll deploy Amiko Pay + Colored Coins myself: I think it's better for me to continue to be available for Amiko Pay development. I'll leave the legal fight to others.

http://computerworld.nl/beveiliging/84556-klpd-had-silk-road-2-0-server-in-mei-al-in-handen (Dutch)

Summary:
The FBI and Europol already knew the locations of the Silk Road 2 servers for a while. In May, the website was hosted at a Dutch hosting provider, and the website was temporarily taken offline to make an image of it. Among other things, the image contains the private key of the TOR hidden service, allowing the police to set up a fake website at the same address. After taking the image, the website was put back online.

The police does not want to say which hosting provider was hosting the services. Apparently, the hosting provider was not only forced to remain silent, but also to lie to the SR2 operator about the cause of the down-time.

The exact timing of the down-time has been used as evidence by the FBI that this was the Silk Road 2 server.

Apparently, the suspect rented the servers under his own name:
http://webwereld.nl/beveiliging/84411-silk-road-2-baas-draaide-server-op-eigen-naam (Dutch)

A total of 9 dark markets were taken offline, including SR2, Alpaca Market and Cannabis Road. This was done at 5 physical locations in North Holland and Utrecht (apparently all in the Netherlands). Ten exit nodes (belonging to the German non-profit "TorServers") were taken offline, four of them were running on a single server in the Netherlands. That server was hosted by hosting provider "NForce".

I made a piece of software which
* retrieves the private key of a given address with the dumpprivkey command
* decodes the private key according to the Wallet Import Format
* gives the private key to OpenSSL (based on what the Bitcoin source code does), and gets the corresponding public key
* encodes the public key to a Bitcoin address
* checks whether given and resulting Bitcoin addresses are the same.

This works fine for some keys, but not for others. Further investigation showed that it works for keys generated with an old version of BOTG (imported into Bitcoin-Qt), and fails for keys generated by Bitcoin-Qt itself (version 0.8.6). The addresses for which it works have a private key (as returned by dumpprivkey) that starts with a '5', and when it doesn't work, it starts with an 'L'. I've read that the ones that start with an 'L' correspond to "compressed public keys", so that's probably what causes the problem.

Note that my code did not generate any errors: it just returned an address that was different from the original. Among other things, this means the version number in the private key format is the same.

I couldn't find good documentation on how to go from private key to public key, either for compressed or for non-compressed keys, so I'll use the Bitcoin source code again to help me. I'd appreciate it if somebody could document this (also, just in case I can't figure it out from the code). Apparently, just saying "this is the private key, and this is the ECDSA curve you should use" is not enough.

It has been written by some that Bitcoin's issuance of new bitcoins to miners is modeled to resemble mining of things like gold. However, I think there is a difference, and it is possible to make a Bitcoin-like crypto-currency which better resembles gold. This might decrease price fluctuations.

The supply of gold depends on the gold price(*): when the gold price rises, gold mining becomes more profitable, and therefore more people enter the business, old mines are re-opened & so on. The opposite happens when the gold price drops. This dampens fluctuations in the gold price a bit, since increased mining increases supply, which tends to decrease the price. The reason this happens is because some gold mines are more profitable than others, and the lesser profitable ones are only profitable when the gold price is high. Also, some people are probably more skilled/productive than others, so that some people can only make a living(**) from gold mining when the price is high.

In Bitcoin, OTOH, supply is only a function of time, and does not depend on the price. I guess the result could be that there is less of a supply-side dampening of price fluctuations than in the case of gold.

I think the gold situation (with more and less profitable mines) can be modeled in a crypto-currency by making the block reward dependent on the amount of PoW. You should see the to-be-issued currency as a to-be-mined precious metal, and some of it can be mined easily (requiring little PoW), while other parts requires more PoW. The required PoW should go to infinity(***) as the total to-be-mined currency approaches the maximum, so that no amount of PoW can ever let the total amount of currency exceed the maximum (e.g. 21 million).

Then, at any moment of time, the total PoW of all blocks and the total mined currency should match, according to the pre-defined curve of currency-as-a-function-of-PoW. Each block contributes a bit to the total PoW, and should be rewarded accordingly with new currency. The average time between blocks can be kept constant, just like it is now, by requiring an adjustable minimum difficulty per block

The result would be that, when the currency price drops, mining becomes less profitable, some miners quit, and the difficulty drops. As a result, the amount of newly created currency per unit of time would drop too. This would dampen the price drop. The opposite would happen in case of a price increase.

(*) If you see gold as the absolute norm of everything, then don't read this as "gold w.r.t. fiat", but rather "gold w.r.t. typical cost of living".
(**) or a better living than alternative occupations.
(***) or to breaking of the PoW hash function, which is actually a finite difficulty

This idea suddenly popped into my head, and I just had to write it down to see whether it's feasible:
https://github.com/cornwarecjp/amiko-pay/blob/master/doc/pay%20with%20blockchain%20knowledge.md

I admit that, with the final script being even larger than shown here, transaction fees will probably be quite large, but as long as the transaction value is more than the fee, it might be worth it. Please note that, in the context of the problem I'm trying to solve, these scripts will rarely be actually published on the block chain, so the average fee you'll have to pay will be much lower.

[Should I fix the wiki page?]

I'm trying to decide what kind of Bitcoin scripts to use for my application, based on information from bitcoin.it.

https://en.bitcoin.it/wiki/Script:
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero).

OP_CHECKMULTISIG	For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
OP_CHECKMULTISIGVERIFY	Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
OP_VERIFY	Marks transaction as invalid if top stack value is not true.

https://en.bitcoin.it/wiki/Contracts:
Section "Theory":
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY

I don't understand this: if this is signed with two signatures, then the boolean output of the CHECKMULTISIG part will be popped from the stack by the VERIFY part. So, evaluation of correct signatures ends with an empty stack, unless scriptPubKey contains another, redundant "True". I'd say that, according to the validity condition described on the Script page, an empty stack would NOT be valid, since it does not contain a top element that is True. So, CHECKMULTISIG should be used here instead of CHECKMULTISIGVERIFY.

Should I fix the wiki page? Is the use of CHECKMULTISIGVERIFY really wrong here? Why does it say CHECKMULTISIGVERIFY in the first place? Is this old obsolete/deprecated? I see CHECKMULTISIG being used in other places, so I suppose that, at least, that one is not wrong.

Which of the two is considered to be a "standard" multisig script by the Satoshi client?

I have basically the same question about EQUALVERIFY vs. EQUAL, but I suppose this isn't a standard script yet:
<key> CHECKSIGVERIFY SHA256 <hash of secret x> EQUAL[VERIFY]

PS. I just read about the bug in CHECKMULTISIG (popping an extra value). Is it also present in CHECKMULTISIGVERIFY? Does this mean that, in the CHECKMULTISIGVERIFY example above, the signer is supposed to add an extra unused value to scriptSig?

Can someone please try to replicate this result listed below? My system is Debian 7.5 + Bitcoin 0.8.6 + clamscan from the Debian distribution.

Are these false positives?

Code:

user@host:~/.bitcoin/chainstate$ clamscan *
141437.sst: OK
141438.sst: OK
[snip]
142245.sst: OK
142246.sst: OK
142247.sst: Gergana.9 FOUND
142248.sst: OK
142249.sst: OK
[snip]
142408.sst: OK
142409.sst: OK
142410.sst: Boot.Gen.10past3 FOUND
142411.sst: OK
142412.sst: OK
[snip]
142469.sst: OK
142470.sst: OK
142471.sst: Stoned.1 FOUND
142472.sst: OK
142473.sst: OK
[snip]
142530.sst: OK
142531.sst: OK
142532.sst: Vienna-645.A FOUND
142533.sst: OK
142534.sst: OK
[snip]
142551.sst: OK
142552.sst: OK
142553.sst: Gen.805 FOUND
142554.sst: OK
142555.sst: OK
[snip]
142566.sst: OK
142567.sst: OK
142568.sst: Italian.1 FOUND
142569.sst: OK
142570.sst: Chren-4016 FOUND
142571.sst: OK
142575.sst: OK
[snip]
142606.sst: OK
142607.sst: OK
142608.sst: Peace.1 FOUND
142609.sst: OK
142610.sst: OK
[snip]
143723.sst: OK
143724.sst: OK
CURRENT: OK
LOCK: Empty file
LOG: OK
LOG.old: OK
MANIFEST-143669: OK

----------- SCAN SUMMARY -----------
Known viruses: 3393590
Engine version: 0.98.1
Scanned directories: 0
Scanned files: 262
Infected files: 8
Data scanned: 470.01 MB
Data read: 511.32 MB (ratio 0.92:1)
Time: 56.098 sec (0 m 56 s)

http://www.multiscope.nl/organisatie/nieuws/berichten/75-nederlanders-kent-bitcoins-1-heeft-bitcoins.html

Eerlijk gezegd overtreffen de getallen mijn verwachtingen.

I made a chart of the volatility of Bitcoin, and how it changes through time:

Apologies for the poor chart quality; I'm more interested in the discussion than in making good-looking charts.

I don't know what is usually used as measure of volatility, but I took the ratio between the highest and the lowest price in a certain time period. I plotted the logarithm of this to make some of the smaller details better visible. I plotted the volatility for 1 day, 7 days and 30 days, based on the daily MtGox USD/BTC price from bitcoincharts.com.

As a general guide to the vertical scale:
1 means: high = 10 * low (so about 900% price change in the given time period)
0.2 means: high = 1.6 * low (so about 60% price change in the given time period)
0.1 means: high = 1.26 * low (so about 25% price change in the given time period)

Question:
For Bitcoin to become useful as a currency, isn't the volatility supposed to become lower, when adoption increases? I think we've seen lots of increase in adoption, but this chart shows little reduction in volatility. Please note that typical volatility levels are REALLY HIGH: we still have a long way to go when it comes to reducing volatility.

What is needed to reduce volatility? Should Bitcoin become "boring" so that we won't have a massive influx of new money in short time spans? Should there be more merchant acceptance? Should there be more "calm, rational" speculators who buy near the bottoms and sell near the tops?

[Nout Wellink, former president of De Nederlandsche Bank (DNB) and current supervisor of the Chinese state bank, considers bitcoins to be worse than the tulip mania of 1636. According to him, the virtual currency is a hype.]

http://nutech.nl/internet/3645557/bitcoin-erger-dan-tulpenmanie.html (Dutch)

Translation:
(Edit 2: Refined the translation and added formatting)

Nout Wellink, former president of De Nederlandsche Bank (DNB) and current supervisor of the Chinese state bank, considers bitcoins to be worse than the tulip mania of 1636. According to him, the virtual currency is a hype.

"Back then, at least you got a tulip. Now you get nothing", Wellink said on Wednesday, during a meeting with students of the University of Amsterdam.

During the discussion meeting Room for Discussion, he described the virtual currency as a hype and found that "this structure" will collapse sooner or later.

Previously, the DNB and Finance Minister Jeroen Dijsselbloem warned for virtual currencies like the bitcoin. The exchange rate of the virtual currency is very volatile. Strong peaks are followed by deep valleys, often without any obvious reason.

During the Dutch tulip mania, around 1636-1637, the tulip bulb was hugely valuable. After a sudden decrease in price, many tulip traders were bankrupted. Economists see it as the first well-described economic bubble in history.

This news is already a couple of days old, but I thought it would still be relevant, since the article says this man is now a supervisor of the 'Chinese state bank' (actually the Bank of China according to Wikipedia).

[Answer from the Minister of Finance to questions from the member Nijboer (PvdA) to the Minister of Finance on the rise of Bitcoin as digital currency(submitted April 10, 2013)]

Already discussed in the Dutch subforum, but I thought it would be interesting for the international community, so I made a translation.

Note: I'm not a lawyer and I'm not a professional translator. I might change this translation in the future if I receive suggestions for improvement.

Original (Dutch):
http://www.rijksoverheid.nl/bestanden/documenten-en-publicaties/kamerstukken/2013/06/07/antwoorden-op-vragen-bitcoin/antwoorden-op-vragen-bitcoin.pdf
My translation:

Answer from the Minister of Finance to questions from the member Nijboer (PvdA) to the Minister of Finance on the rise of Bitcoin as digital currency
(submitted April 10, 2013)

Question 1
Are you familiar with the news item "Bitcoin is investment with unprecedented performance, but limited payment method'? [1]

Answer to question 1
Yes

Question 2
How do you interpret the rise of the digital currency Bitcoin? Do you share the concerns about the stormy rise in value of this payment method linked to the limited supervision on (the safety of) the payment system?

Question 4
What is your view and the view of the Dutch Central Bank (DNB) on the use and emergence of parallel currencies in general?

Answers to questions 2 and 4
The rise of the alternative virtual currency Bitcoin currently mainly appears to be determined by speculative demand for this.

The alternative virtual currency Bitcoin has partly the same and partly different characteristics compared to traditional payment methods. The difference is mainly that the parties involved in traditional payments, such as banks, clearing houses, supervisors and monetary authorities, are lacking in Bitcoin. Its use is not subject to any form of financial supervision from the government and the deposit guarantee scheme does not apply to Bitcoin. In general, the experience of central banks is that alternative, whether or not virtual, currencies have an unstable character, which entails risks for users. However, in my view, there is currently no risk of financial instability, because of its limited size, low degree of acceptance and the limited connection of Bitcoin to the real economy.

Since long term increase in the use of alternative (virtual) currencies is not ruled out, these developments are being tracked by the Dutch Central Bank -
also in the context of the ECB [2].

Question 3
Is it known to you on what scale Bitcoins are being used in the Netherlands and does an estimate exist of the value of Bitcoins in possession of the Dutch?

Answer to question 3
No, as yet, no research has been done in the Netherlands because of the lack of relevance. However, in its publication in October 2012, the ECB  indicated that at that time globally 6.5 million Bitcoins were shared by 10 000 users [3]. Other public sources suggest that there are currently more than 11 million Bitcoins in circulation, with a value of approximately 1 billion euro. A maximum of 21 million can be brought into circulation. From public sources [4] can be derived that the number of Dutch active in the buying and selling of Bitcoins is limited; about 2% of the total number of users (for approximately € 20 million). Now since, in addition to that, these activities primarily seem to have a speculative character, the share of Bitcoin in, and any impact on the real economy is still negligible.

Question 5
Is monitoring and / or investigation carried out on the possible use of Bitcoins as an instrument for laundering of criminal money or hoarding of illicit money?

Question 6
Is it permitted for private parties under European or national law to develop an alternative (digital) currency and and use it commercially (on a large scale)?

Question 7
In your opinion, do the activities as performed by Bitcoin fall under the Financial Supervision Act (Wft) or this a private activity?

Answers to questions 5, 6 and 7
Anyone is free to develop and/or use alternative (digital) products, as long as it does not conflict with the Dutch law, such as the Law on gambling.

The current understanding is that Bitcoin is not electronic money as meant in the Financial Supervision Act, partly because Bitcoins are not issued in exchange for received money and they do not represent a claim on the issuer. Because of this, Bitcoin does not meet at least two of the four requirements set out in the law. Also, Bitcoin is not in any other way a financial product as meant by the law. (Mediation in) the purchase or sale of Bitcoins is not a financial service either, so the Financial Supervision Act does not apply.

With regard to investigation, the FIOD, from its investigative task, has attention to the possible use of Bitcoins in money laundering. Research will
have to show to what degree Bitcoins are being used for criminal purposes and how the FIOD will respond to that in the future. For this, there is a close cooperation with the High Tech Crime Unit of the Police.

Also at the strategic level, there is attention to developments in this area.  For example, there is the cybercrime consultation, chaired by the Department of Security and Justice, in which the Public Prosecution Service, the FIOD and the National Police are represented.

Question 8
What is the status of Bitcoin under Dutch tax law; do taxes have to be paid over sales, wages, profits or capital paid or held in Bitcoins?

Answer to question 8
A taxpayer who has a source of income with activities in the course of trade, such as income from business or income from an activity, will have to pay taxes over that in compliance with the provisions of the Income Tax Act 2001. The fact that the benefits from such a source are calculated using a scheme other than the legal tender in force in our country does not make a difference. Such a benefit in the form of a result in Bitcoins will also lead to taxation. However, the determination of a taxed income will mean that the value of the results achieved in Bitcoins must be converted into an amount in euros. For the wage and sales tax, a similar approach applies.
Finally, I point you to a previously released policy decision on the tax treatment of local money systems where similar problems exist [5].

1
Het Financieele Dagblad.
"Bitcoin is investering met ongekend rendement, maar beperkt betaalmiddel'.
April 9 2013.
2
See ECB report of October 2012 on 'Virtual Currency Schemes',
http://www.ecb.int/pub/pdf/other/virtualcurrencyschemes201210en.pdf
3
ECB report of October 2012 on 'Virtual Currency Schemes',
http://www.ecb.int/pub/pdf/other/virtualcurrencyschemes201210en.pdf
4
http://bitcoinstatus.rowit.co.uk/countryHostsMonth.png
5
Decision of 1 December 2008, no CPP2008/520M, Stcrt. 2008, 243.

(last status update: Dec 4th 2014)

I'd like to use this thread to keep you informed about development progress of Amiko. Whenever practical (e.g. software development) issues pop up, I'd also like to discuss them here. Concept choices are better discussed in the threads that describe these concepts.

You don't know Amiko? It's basically an implementation of the ideas in these threads:
https://bitcointalk.org/index.php?topic=94674.0
https://bitcointalk.org/index.php?topic=152334.0

You can find the latest source code on Github:
https://github.com/cornwarecjp/amiko-pay

Code:

Plan + completion status:
[90%] Concept design
[75%] Development of proof of concept prototype
[ 0%] Security hardening
[ 0%] Development of usability features
[10%] Documentation
[ 0%] Beta testing, processing user feedback
[ 0%] Deployment, marketing etc.

Code status (will improve in time):
* Usefulness: no known use cases
* Security level: has known security holes
* Documentation level: current feature set is mostly documented

For now I have some practical questions:

1) What is the best way to connect to the bitcoind RPC interface from C++? Is it a good idea to just copy some RPC code from the Bitcoin source code?

2) Since Amiko will depend on bitcoind for a lot of things already, I'm considering using Bitcoin as a private key storage for Amiko. That way, I don't have to re-invent the wheel for a secure (encrypted etc.) storage method. Is this a good idea? It would mean that the private keys have to be transferred through the (unencrypted) RPC connection from Bitcoin to Amiko (e.g. with the dumpprivkey command). It would also mean that Amiko has to have the passphrase for unlocking the Bitcoin wallet; how should the passphrase be stored? Maybe it shouldn't be stored at all, but provided by the user at start-up of Amiko?

3) Are there any resources on how to best use testnet? E.g. I've read there were some problems in the past with testnet mining; do I need to do my own mining? Is there a place to get some testnet coins for free?

[What?]

(note: new ideas are posted further down this thread)

What?
A method for massively reducing initial blockchain download for full nodes

Why?
In order to validate a transaction, you basically need to check the following:

• the scriptsigs of its inputs match the scriptpubkeys of the outputs of the "source transactions" (this is a simplified description)
• the "source transactions" are all valid
• the transaction is not a double-spend of another transaction

Maybe I forgot some checks, but the point I want to make is: the last of these checks can only be done if you have access to all transactions, so you need the whole block chain, at least starting from the block that contains the oldest "source transaction". Since there will always be some very old unspent transactions (e.g. ones for which the private key was lost, without any proof that it was really lost), in practice you'll need the entire block chain in order to be able to validate arbitrary transactions.

You can also do that last check if you only keep track of the unspent transactions: if you know all the unspent transactions, you can forget all the spent transactions: you know a transaction isn't a double-spend if all its inputs come from unspent transactions. If, at some point in time, you know all unspent transactions, you can continue to keep track of the changing set of unspent transactions. The problem is in initialization: when you first set up your node, the only way to find out which transactions are unspent, is to download the entire block chain. This also means there need to be plenty of other nodes which can give you the entire block chain.

Initial block chain download is already a big PITA now, and it is only going to be worse in the future: the block chain can only grow. One might argue that only the miners (or maybe only pool operators?) really need to validate a transaction, and that other people can generally trust a transaction when it has been included in the main branch of the block chain. However, this kind of reasoning forgets the following:

• Mining (including the transaction validation) is meant to be a massively decentralized community effort, not something that is done by some pool operator aristocracy.
• The truth about which transactions have happened is meant to be publicly readable, not to be held only in the secret books of the pool operator priesthood.

The validation elite should be so large that it becomes completely unfeasible for its members to cheat on the "non-elite" by conspiracy. So, it should always be easy for new people to enter this elite. As described above, initial block download is an essential part of this, and it should be as painless as possible. We need some way so that it is only necessary to download and store the block headers and the unspent transactions (with the partial Merkle trees of the unspent transactions, as described by Satoshi). Even full nodes should be allowed to forget spent transactions.

How not to do it?
You might simply ask other (full) nodes which transactions are unspent. There are some checks you can perform on whether the answer is honest, e.g. the unspent outputs should add up to the total number of mined bitcoins, and the transactions shouldn't be double spends of each other, but there are no sufficient checks to make certain that you have the correct set of unspent transactions. Worse: if the total amount in the outputs adds up to more than the number of mined bitcoins, you have no way of knowing which transaction is wrong: you can only do that by retrieving spent transactions, so you still need other nodes to give you the spent part of the block chain.

How to do it?
For every block, or maybe once every so-many blocks, make a Merkle tree containing ALL UNSPENT transactions of that moment, including the ones that were already included in the block chain. Include the root hash of that Merkle tree in a block (preferably in the block header, but otherwise in a fixed place in the block Merkle tree). The "unspent transaction" Merkle tree should be made in a deterministic way (e.g. sorted by transaction hash) so it can be validated by checking the root hash value only. Miners should only build on top of a block if they have checked that the root hash of the "unspent transaction" Merkle tree is correct. Blocks with an incorrect root hash should be rejected.

Now, a new full node doesn't need to download the entire block chain anymore. It just needs to find the longest proof-of-work chain of block headers, download the most recent(*) "unspent transactions" Merkle tree and download all transactions that happened after that point.

How to improve this idea?

• If this new Merkle tree is included in every block, maybe it can completely replace the traditional way of putting transactions into blocks?
• What would be the best way to sort transactions in this new tree? Preferably, it should not be necessary to rebuild the entire tree in order to update it with new transactions.

(*) for security, take one that already has a high number of confirmations

I am starting a Bitcoin-related coding project, and since it's dealing with Bitcoin transactions, it can become an interesting target for hackers. I'd like to do everything I can to make my code hacker-proof. I guess that in the Bitcoin developer community I'm not the only one who has to deal with this, so I want to ask: does anyone have a list of rules to follow when writing secure code?

My current project is written in C++ (without Boost), but in the future I'm interested in Java too.

So far, I've come up with the following list:

• Know how to code. Don't make bugs, test everything, keep your code easy to understand etc.
• Know the language you're using, and follow its best practices, in order to avoid bugs and keep your code readable.
• Don't make any assumptions about input data. Do a complete validation on input, especially input from untrusted sources.
• When using libraries, only use ones you trust.
• Have clearly defined (and secure) behavior for all error situations (invalid input, out of memory, failing library call etc.)
• When using cryptography, stick to existing practices as much as possible. Whenever you do things differently, make a detailed analysis of your design. Know the properties of the cryptographic primitives you're using. Use existing encryption and hashing primitives if you're not a cryptography professor (or equivalent).

Right now, my most important questions are:

• How to use OpenSSL the right way for setting up a TLS connection. It's going to be a new protocol, so there's no need for backward compatibility with old insecure SSL/TLS protocol versions. It's P2P, so there's no clear client/server hierarchy, but obviously there's one peer that offers a connection and another peer that connects to it. I might want to use alternative key authentication mechanisms besides CA's; I'm mostly thinking about namecoin for that purpose, but web-of-trust or user-defined (ssh-style) are also options.
• How to do error handling. It seems right now that every three lines of code or so can potentially create an error, and I want a convenient way to deal with them. Is it a good/secure idea to use exceptions for this in C++? The most basic error handling would be to log the error and exit: that would allow a DoS attack but at least that's not the worst possible consequence of an attack. For errors in incoming data, I'd have to write friendlier exception handlers, to prevent DoS.

http://blog.iusmentis.com/2012/12/10/bitcoin-exchange-krijgt-status-van-bank/

Over de "bank-status" van Bitcoin-Central, belastingen over Bitcoins, belastingen over mining-inkomsten en belastingen over diverse andere virtuele goederen.

Recently, bitcoin.de changed its SSL certificate (twice), while the old one wasn't expired yet. Also, the certificate authority changed. bitcoin.de now seems to be some kind of alias(?) of ssl2669.cloudflare.com, and Certificate Patrol shows it like:

- GlobalSign Root CA
  - GlobalSign Organization Validation CA - G2
    - ssl2669.cloudflare.com

For bitcoin.de, this might have had something to do with the recent DDOS attack (but then, who would gain anything with a DDOS attack?). But now I also got a new certificate for bitinstant,com, also while the old certificate wasn't expired yet, and also pointing to ssl2669.cloudflare.com.

Can someone please explain what is going on here?

[Knowledge center]

My proposal is to split up the Satoshi client into several smaller software projects. It should be possible to run each component as a separate executable (and let the components communicate e.g. through RPC), but it should also be possible to compile them into static or shared libraries, which can be combined into a single executable.

I was thinking of the following subdivisions, but core Bitcoin developers might have better ideas:

• Knowledge center: this keeps track of known transactions and blocks, and their status
• P2P protocol handler: exchanges information between knowledge center and other nodes on the Internet
• Block chain storage: performs loading/storing of transaction information to/from knowledge center
• Verifier: checks validity of transactions and blocks, and notifies knowledge center of the result
• Miner: creates new blocks (gets transactions from knowledge center and submits blocks into it)
• UI: shows information to user and allows user to perform actions.
• Wallet: stores private keys and creates/signs transactions on request by UI

This will have several advantages:

• Each individual component is smaller, and hence its code is easier to understand than its equivalent in a monolithic client. This is mostly because the split-up architecture itself creates a good overview, and because the interfaces between the components are (assumed) well documented.
• Derived from this: this allows more developers to get involved in development of the software. It can also act as a guideline for organizational subdivision, where development of each component can have a different "lead developer".
• Also derived from having better understandable code: security will improve.
• Security will also improve because each module will have only a subset of all threats to worry about. The more paranoid / high-volume traders can improve security by running each component as a separate process in a specialized minimum-privilege security context.
• Innovations in different components can be developed more or less independently from each other. People can use a drop-in replacement for one component, while keeping the other components unchanged. For instance, people can make UI components with added functionality, or use a brain wallet component instead of encrypted storage on disk. Or one can replace the knowledge center with something based on services like blockchain.info (or use a less-radical idea for making a lightweight client). Some innovations require interface changes between components; to allow this, I think the interfaces should be extensible (similar to the OpenGL API)

For efficiency, I think there can be some "shared code" between these components, e.g. class definitions with serialization functionality, and code for making the (RPC?) interfaces. In order not to undo the advantages of splitting up the code, the "shared code" should contain as little functionality as possible.

Al weer vrij oud, maar ik zag nog geen link in dit forum:
http://www.volkskrant.nl/vk/nl/2844/Archief/archief/article/detail/3223214/2012/03/10/De-digitale-onderwereld.dhtml

tl;dr: behoorlijk negatief artikel dat een link legt tussen TOR en Bitcoin, en kinderporno en online criminaliteit. Ronald Prins verdedigt wel het bestaansrecht van TOR vanwege de positieve toepassingen (voorbeeld: Arabische lente).