theymos (OP)
Administrator
Legendary
 Offline
Activity: 5194
Merit: 12972
|
 |
November 17, 2010, 01:52:11 AM |
|
Generation transaction d5d27987d2... appears in block 91812 and 91842. This is probably an accidental side-effect of miners that reuse keys.
How does Bitcoin handle this conflict when these transactions are redeemed? I haven't found anything for this situation in the code. If it's not handled, are all such transactions worth only the value of one?
(Bitcoin Block Explorer isn't handling this correctly, but I don't have time to fix it right now.)
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
|
|
|
|
|
|
|
|
|
The trust scores you see are subjective; they will change depending on who you have in your trust list. |
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
ByteCoin
|
|
November 17, 2010, 05:05:42 PM
Last edit: November 17, 2010, 05:22:46 PM by 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
|
|
|
|
|
theymos (OP)
Administrator
Legendary
Offline
Activity: 5194
Merit: 12972
|
|
November 17, 2010, 05:13:18 PM |
|
Oh no! That's really bad!
Not really. The effect is limited to the people who create these transactions (which stock Bitcoin would never do). I probably should have specified in the OP: this is not a problem with the cryptography. These miners are actually creating transactions that are exactly the same. |
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
SmokeTooMuch
Legendary
Offline
Activity: 860
Merit: 1021
|
|
November 17, 2010, 05:20:46 PM |
|
so ... how did something like that even happen ?
|
|
|
|
|
ByteCoin
|
|
November 17, 2010, 05:24:19 PM |
|
so ... how did something like that even happen ?
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 |
|
|
|
|
theymos (OP)
Administrator
Legendary
Offline
Activity: 5194
Merit: 12972
|
|
November 17, 2010, 05:29:22 PM |
|
so ... how did something like that even happen ?
Generation transactions aren't very different from one another if you modify Bitcoin to re-use the same key for every generation. The only real difference between them at this point is the extraNonce value, which has a relatively small range of typical values. This is not a fault in Bitcoin, but in someone's custom miner. (Maybe the network should have rejected the transaction. No harm done to the network, though.) |
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
|
ByteCoin
|
|
November 17, 2010, 05:45:24 PM |
|
This is not a fault in Bitcoin, but in someone's custom miner. (Maybe the network should have rejected the transaction. No harm done to the network, though.)
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 |
|
|
|
|
theymos (OP)
Administrator
Legendary
Offline
Activity: 5194
Merit: 12972
|
|
November 17, 2010, 05:51:40 PM |
|
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 miners are mining wrong. You need to prevent this situation from happening. The network can't do it for you. |
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
|
ByteCoin
|
|
November 17, 2010, 06:01:14 PM |
|
The network can't do it for you.
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 |
|
|
|
|
FreeMoney
Legendary
Offline
Activity: 1246
Merit: 1014
Strength in numbers
|
|
November 17, 2010, 07:35:51 PM |
|
The network can't do it for you.
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 What if you modify your client so that the coins are sent to an address for which no private key was generated? Is the network still at fault? I don't know enough to have an opinion of this particular situation, but obviously to some extent custom miners need to make sure they understand how the network works. If somehow it was said or implied that what they were doing would be fine, then obviously that should be fixed or made clear. |
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone. |
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1007
|
|
November 17, 2010, 08:22:18 PM |
|
The network can't do it for you.
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 What if you modify your client so that the coins are sent to an address for which no private key was generated? Is the network still at fault? I'm pretty sure that the standard client can send coins to an address that doesn't actually exist, if the address is entered by hand and is a valid address by it's checks. |
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
FreeMoney
Legendary
Offline
Activity: 1246
Merit: 1014
Strength in numbers
|
|
November 17, 2010, 09:08:16 PM |
|
The network can't do it for you.
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 Yeah, I think that is right. I was thinking more if you sent your generates to go to unowned addresses, but the point is the same, there is some obligation to know what you are doing, the network can't magically fix mistakes people make. What if you modify your client so that the coins are sent to an address for which no private key was generated? Is the network still at fault? I'm pretty sure that the standard client can send coins to an address that doesn't actually exist, if the address is entered by hand and is a valid address by it's checks. |
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone. |
|
|
|
ByteCoin
|
|
November 17, 2010, 11:18:28 PM |
|
Yeah, I think that is right. I was thinking more if you sent your generates to go to unowned addresses, but the point is the same, there is some obligation to know what you are doing, the network can't magically fix mistakes people make.
What if you modify your client so that the coins are sent to an address for which no private key was generated? Is the network still at fault?
I'm pretty sure that the standard client can send coins to an address that doesn't actually exist, if the address is entered by hand and is a valid address by it's checks. 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. |
|
|
|
|
|
m0mchil
|
|
November 18, 2010, 07:54:39 AM |
|
I am really worried about this. It's highly possible that the problem is in my getwork patch, now used by many. I would really appreciate someone taking a look at the patch, specifically the CheckWork() and PrepareWork() functions in main.cpp Yes, it is reusing a key from the pool, but if block is found the key is never used again. Both functions should be thread safe. Theymos, are there other such generations? |
|
|
|
theymos (OP)
Administrator
Legendary
Offline
Activity: 5194
Merit: 12972
|
|
November 18, 2010, 03:01:48 PM |
|
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
|
