[Why did you buy or sell?]

Ethereum trading is open for a few days now. Why did you buy or sell? It will be interesting to see what motivations people have for trading.

Please only comment if you actually made a trade and put money where your mouth is. We don't need further loose predictions from non-stakeholders here.

[lockunspent]

In Bitcoin Qt, I tried to lock unspent outputs. My intention was to lock all but one to force a particular output to be selected for a transaction.

I understand it should work like this:

• call lockunspent with a list of outputs
• call listlockunspent and observe that all specified outputs are actually locked

Unfortunately, none are locked in my testing. What am I doing wrong? There was no error message. I entered the command in the debug window.

Edit: I reviewed the source code and I did not find any obvious usage errors on my part. Debugging the client is beyond my abilities, though.

I want to transfer all BTC into a new fresh wallet (because the old one might have been leaked). That can be done of course with a simple "send bitcoins". But because all your coins go to a single address now everybody knows that all your old bitcoin addresses belong to one person.

Is it possible to send from a single address all money that it has available to a new address (in the new wallet)? That way you could transfer your money address-by-address and avoid mixing the money.

Most transactions have 2 output (I understand why) but what does it mean to have many outputs? Such transactions cannot be created with the standard bitcoin client (?). Why are people doing this and using what tool?

Example: http://bitcoincharts.com/bitcoin/#bafb4c5a7e3fadcedc7ca2ab507c4c6ec3d1f8ee2a7b00e676af99c13d7aeecf

(still unconfirmed)

When transaction load increases we need a system that allows most clients to function without all transaction history. The system must also still be attack-proof so we cannot offload history on a small number of supernodes - they might get under control of an attacker.History must be spread across all clients randomly.

I propose to insert into every block 1000th block N a summary of all balance differences that resulted from transactions in the block range [N-20000 to N-10000). Clients only need history to ensure that current transactions have enough balance on their inputs. We can store that balance data as a cache inside of the network. The important bit is that this data is validated through the block chain so clients can trust this data (they would not be able to trust it if it was stored inside of a DHT in the P2P network). Only if clients can trust this cache they do not need to download, verify and store the blocks [N-20000 to N-10000).

In order to still preserve all information in the network clients still download 1-10% of the ranges they don't actually need (amount depending on available disk space). That way we save 90-99% of storage space while preserving all data.

Currently there is one block chain that contains all transactions. This will become a scalability problem at transaction rates that VISA has (2000tps). To spread the load we could allow a block to split into N child blocks instead of exactly one. That would create multiple chains spreading the load. Multiple chains could be joined if transaction load declines by having a single child block for multiple predecessors. Wo would get a directed acyclic graph (DAG) instead of a linked-list.

We could program clients with the following rules:

- Transactions appearing in any branch are valid just like now a transaction in the main line. All branches are equal
- Miners can split and join chains as they see fit under the following rules:
 * A block has a maximum size of 1MB. If more, then a split must occur
 * The least amount of split nodes must be used to fit the 1MB rule
 * Two chains can only be joined if the 1MB rule is not violated
 * A chain must have at least 1000 blocks before it splits or joins (just like transactions are currently required to "harden")
- We would need to find a way to let every client apply his unit-of-work to as many chains as he likes in order to keep the system scalable and fast

This would balance the load across as many chains as necessary and still keep a single address space - no hub chains or exchange rates between chains required. We only make changes on the "storage layer" of the blocks. Their meaning is unchanged.

Is this feasible?

Currently, the wallet is stored inside the wallet.dat file. There are three potential problems for an ordinary end-user:

1) The wallet gets lost and all bitcoins are lost too
2) A virus gets on the machine and immediately sends away all the money to an anonymous address
3) A virus gets access to a backup of the wallet.dat and proceeds as in (2)

I think the latter two are commonly disregarded. There _will_ be viruses doing a routine check for bitcoin wallets and sending them away in an instant. We must also assume that sometimes a users machine will be compromised. I propose new features in the client to address (2):

It should be possible for a user to encrypt the private keys (or the whole wallet.dat) with a password. The following properties should hold:

- The keys do not exist in memory or on disk for longer than necessary. After use they are wiped.
- Consequently, before every action that requires the keys, the password must be given
- While entering the password, bitcoin.exe switches to a secure desktop like Vista UAC does. This is not a security boundary (meaning it can be circumvented by a virus) but it provides defense in depth - it makes it harder to steal the keys. A screen keyboard should be given so standard keyloggers do not succeed.

Problem (3) is still adressed by the password beeing required to decrypt the keys.

Some of these measures might seem overkill but after all we are dealing with a sizable financial value here. The bitcoin client is like the online banking interface that we all use every day. The difference is sending the money away is untracable, instant and does not require PIN or TAN.

Feedback welcome!

Veralteter Thread.