I'm not advocating that the standard client attempt to prevent people from their forseeable consequences of their own decisions. The blame for the "loss" of 50BTC in this case lies squarely with the standard client/protocol as I explain below.

The key point is the implied contract between the generator and the standard client. If the network accepts the new block then it should reward the miner with 50BTC that the miner can dispose of as they choose. If the miner wants to send it to an un-owned address then that's fine. In this case, the miner clearly made the effort to allocate the coins to himself and the uselessness of those coins is purely due to the fact that the network just happens to identify coins by their hash and there was a hash collision with some other coins.(Slight simplification of the real situation to save space). The assumption behind the design decision to identify transactions only by their hash was the expected uniqueness of hashes. Proper efforts are made in other areas of the code to ensure the truth of this assumption. The fact that no adequate efforts are made here is a flaw.

ByteCoin

PS I (and at least one more person) have sent coins to un-owned addresses. The fact that this is permitted is fine.

It's a very handy tool.

It would be good (for me at least) if there was a field in the "Block" view that gave the length of the block in bytes. It would be nice to have a size column which gives the transaction size in bytes and a priority column which shows the priority as calculated using the recently implemented formula.(Priority no sooo important to me at the moment though.)

On the "From" and "To" columns it would be nice to see the "balance" associated with that public key before the transaction so that a coinbase transaction would say for 91812
16va6NxJrMGe5d2LP6wUzuVnzBBoKQZKom:0 +50 = 50
and the other transaction would show as

777ed67c58... 0 1BFrS5LQSTY... : 1 -1 = 0 16QjxpGVX6EF... : 19 -19 = 0   1MCwBbhNGp5hR...: 411.9 +20 = 431.9

You can imagine that it's handy to have this info at block level without having to drill down to transaction or address level.

Also, it would be very interesting to have a list of unspent addresses and their balances. Obviously this total should add up to the currentblocknumber*50

If you wanted to be a hero you could work out how much space could be recovered from the block chain by removing spent transactions and stubbing the merkle tree down as much as possible. I suspect it wouldn't be much at the moment.

If you wanted a tougher task and be a real hero you could create a graph of bitcoin transactions with each address being a node and each transaction being a directed edge. You could display the thickness of the edges as being the number of transactions or the total value and see how many isolated graphs the transactions fall into.

The last two are harder more long term projects but the block page changes would be very handy for me in the short term.

Thanks theymos

ByteCoin
 

 

Yes it can. The network should demand that valid blocks have the block number hashed into the coinbase before accepting the block. The way that hashed transaction values are used in bitcoin demands that reasonable effort is made by all parties to ensure that they are unique. Clients already make a number of checks before accepting blocks and this should be one of them. Of course the onus really falls on the mining clients to check previous blocks. All the more reason why it should be easy to make your own highly optimised mining program without having to worry about keeping the network healthy by ensuring your software performs adequate checks. There should be a mining interface to the current vanilla client.

ByteCoin

There is an implied contract between the miners and the network that the effort that the miners exert to generate blocks is rewarded by 50BTC (at least, and at the moment) which they can spend as long as they take care not to lose their secret key for example. The network is breaking their side of the bargain by not allowing 50BTC rightfully mined to be spent.

The damage to the network is to its reputation and credibility. If you had 50BTC held in some address, if the majority of generating power conspired appropriately, they could arbitraritly fail to accept any transactions using that address. Would you argue that in this case there's no harm to the network too? What about if the miners conspired to exclude all non-fee paying transactions or on some other metric?

ByteCoin

The implementation does not take enough care to ensure that different coinbase transactions have different hashes. That is to say that the "standard" does not mandate that something like the block number *has* to be in the coinbase transaction for the block to be valid.

ByteCoin

Oh no! That's really bad!

Suggested fix: Include the block number in the coinbase.

For discussion: The new client release should, among the other changes, allow an artificial "special" coin generation to credit that public key to compensate for the unusable coinbase credit.

ByteCoin

Well, let's suppose you have a cube of diamond that's 10 metres per side and a computer that can try about 10 million addresses per second. The owner of the computer touches the cube of diamond once in their life so lightly that only one atom is worn away. The owner has a child when they're 26ish who also touches the cube of diamond similarly lightly once in their life etc...
The cube of diamond is completely worn away by the time the computer has exhausted the key space.

ByteCoin

Hmm.. If clients disagree about what the current block count is then they already disagree about whether certain transactions are valid or not and therefore the problem you mention exists already without my proposal.
Please go into more detail about why this is not good for the network.

ByteCoin

Great. So what would you like to buy using Bitcoins and what do you have that you are willing to sell in return for Bitcoins?
Solve that and I'll admit you have a useful app.

ByteCoin

At the moment, if you make a payment to someone but they've wiped their wallet then the coins are irretrievably lost.
Similarly, if the network is flooded with 0.01 fee transactions and you make an urgent payment but forget to include a higher fee then you can't reissue that payment backed by the same coins but with a fee.

If you could cause the current block number to be pushed on the stack and do some maths with it then you could implement a payment that must be spent by the recipient before a certain block number is reached or else the script would allow it to be spent again by the sender for example.

I suspect that this would be a very popular transaction mechanic.

ByteCoin

GPU mining has had an interesting effect on Bitcoin even in the short time I have been involved.

When I first heard about Bitcoin (through Slashdot or similar) I was intrigued by the idea and ran the client to see if I could generate some coins even though it's a non-trivial security risk.  Generating some coins then made me have some sort of emotional investment in the project. Similarly, I think that a lot of people who currently support the project would no longer be so interested if they lost all their coins. I think there's some hostility to people who suggest that the current scheme should be scrapped and restarted in an improved form purely on the grounds that the existing balances might be wiped out.

GPU mining now means that running the client is no longer so apparently rewarding and it means that a lot of the superficial appeal of Bitcoin has gone. A lot of the forum posts have been concerned with valuing bitcoins or predicting the future value while seeming to ignore that you can't actually buy or sell very much with them. I think that the current situation where generation is not a significant factor in most people's decision to support the network is a more realistic environment in which to judge the success of the scheme.

ByteCoin

At the risk of provoking an economics argument, I think that economies are driven by people having supplies and demands that they wish to match up with other people's demands and supplies respectively. The money is just a means of facilitating this. The problem with Bitcoin is that the current monetary system performs this function very effectively and the reason why there's not more Bitcoin activity is that there's not a persuasive reason to engage in it.

If you look at other e-currencies like egold, you can see this effect in action. The illegal money-laundering side of the economy gravitated towards egold because unlike the normal financial system, egold didn't actively discourage it.

So in order to "jump start" the Bitcoin economy you need some application that it can satisfy better than the normal monetary system. Preferably you need an application that isn't arguably illegal or the "authorities" will come down on it like a tonne of bricks regardless of its actual legality - mark my words.
Anyway, that application is not micropayments; Bitcoin isn't good at that. It's not full anonymity either as payments are at best pseudonymous. Nor is it instant irrevocable payments as they take time to confirm.

I think Bitcoin is at the moment and implementation in search of an application. The greatest rewards for using it have so far been intelectual and to me it has the flavour of something released into the wild as an experiment.

ByteCoin

In your initial post RHorning you raised a number of interesting issues and I did not give them an adequate response in my immediate reply.

You think that people should be rewarded for participating in the network by providing network bandwidth for example. This is a perfectly reasonable position and I agree with you. Unfortunately there's no way that I can think of to implement this in the current Bitcoin system without being scammed or having some other negative consequences. If you were to think of a way to implement it and specify it in some detail then I'm sure the proposal would be examined in considerable detail.

It's hard to imagine how network participation would be rewarded because Bitcoin is not good at micropayments. Every payment is sent to each client and gets recorded in the block chain on each client's hard disk. The number of fee free payments per block is relatively low. Let's say you can get 50k of transaction data in a block before you have to pay. Let's say the minimum size of a transaction is 100 bytes (it's actually more) so that's 500 transactions in about 10 minutes or less than one transaction per second and everyone's hard disk fills up at 2.628G bytes per year. Even if one lets the micropayments accumulate on account and you settle it relatively infrequently, it's still going to be a significant proportion of transactions.

The second problem is that any reward that creates coins from thin air has to be mutually agreeable and verifiable. It would be hard to verify that all this network participation was not just falsified to get the money.

The third issue is satoshi's de-facto control over all aspects of Bitcoin. I don't have an opinion about whether this is good or bad, it just is and has to be taken into account. In another thread, gavinandresen opined that it's way too early to start asking for commitments to adhere to a particular interface or functionality. Upon reflection I believe he is right. If you look at the amount of generally useful code written to further the project, essentially all of it has been written and tested by satoshi. Note that I'm not counting GPU miners as useful! Thanks to him, we all have a nice reference implementation of Bitcoin that we can examine and play with and a wonderful forum to share our thoughts. If he discontinued development for whatever reason the project would rapidly grind to a halt. People disagree on what exactly Bitcoin is and how much would have to change before it wasn't Bitcoin anymore. The real answer is that Bitcoin is whatever satoshi implements for the forseeable future. At the moment and for the forseeable future there are a lot of features of the current system that need to be discovered and addressed before an improved system can be designed intelligently. If the current scheme were substantially changed then a lot of the momentum would be lost and it would take quite a while for the new system to reach even the current low level of maturity.

ByteCoin

Brilliant!

ByteCoin

Of course, if the network is not being flooded and you're not overly concerned about the current transaction getting held up then it's probably worth preferring to use your 0 conf transactions so that you can "save" the higher priority coins for when the network is being flooded.

Unless I misunderstand, it looks to me like the current logic is more likely to spend the accumulated priority of older transactions. It's a minor point however.

Gaming the system  by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course!

ByteCoin

If you want to know how to do it with the least effort, just make a number of normal, low value transaction to another address you control and put chunks of the data into the scriptPubKey followed by an OP_DROP.


ByteCoin

Bitcoin rewards user's expendature of CPU time to support the network but does not value their disk space and network bandwidth. You can't change this nor the traceable pseudonymity of transactions without the system ceasing to be Bitcoin.

ByteCoin

I mentioned that a while ago but I realize now that there are more effective ways of storing data in the block chain without incurring any costs. I think you can assume that at the moment an interested party can store something approaching 50k of arbitrary data per block for free. If you generate the block hash yourself, I think it's possible you could store 500k.

The kiddie porn problem is real. I had phrased it in terms of Lady Gaga videos previously.

As far as I can see, nothing effective can be done about it. It's a byproduct of the design.

ByteCoin

Fair enough. I meant that it's not necessary to issue a certificate which represents a certain number of bitcoins in a bank when you can just issue a certificate which encodes the bitcoins themselves.

ByteCoin

That was because the exchange of certificates was a lot more convenient than exchanging the gold.

No similar incentives operate with bitcoin.

ByteCoin