So i should just overwrite the file in both locations each time?
It might be a good idea to save a few old versions. |
|
|
|
|
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.)
|
|
|
|
Anybody can vote, except the prize sponsors of the bitcoin GALORE! meme contest
This does not seem fair. They are providing the money, yet they can't vote? I vote for #2. |
|
|
|
Or alternatively, the network could accept that the MiB now control the world's only block generator, who would now see *all* transactions, and could impose any arbitrary tax on each - a situation even better for the government than with today's paper currency.
Everyone can already see all Bitcoin transactions. Generators can't charge arbitrary fees. Transactions offer a certain fee, and generators can accept the offer by including it in their blocks, or reject the offer and not include it in their blocks. Lower-fee transactions will build up, creating incentive for other people to enter the generating market. |
|
|
|
Yikes, I've got it 4 times in there in the last couple of days. Is that each time I found one and it got longer, or anytime I hopped on the shorter chain?
You're more likely to reorganize right after starting Bitcoin while you catch up with the current blocks. If you were running Bitcoin that whole time, I'm not sure why you would get so many. It only happens when you stop working on one branch and start working on another one. I would be interested in seeing that 24-hour section of your debug.log. |
|
|
|
Does this forum have that capability?
No. It was disabled. Nothing on bitcoin.org ever sends any email. |
|
|
|
Is there any way I can confirm, that someone else generated a block for the same block as me, and then it forked, and the other chain happened to grow longer faster?
Search debug.log for "REORGANIZE" right after your "proof-of-work found". That means another chain has gained the lead over your chain. That's why we have this... // Don't show generated coin until confirmed by at least one block after it
// so we don't get the user's hopes up until it looks like it's probably accepted. |
|
|
|
After investigating some more, I found that nLockTime requires in-memory transaction replacement to be re-activated for it to be useful. if (mapNextTx.count(outpoint))
{
// Disable replacement feature for now
return false;
// Allow replacing with a newer version of the same transaction
if (i != 0)
return false;
ptxOld = mapNextTx[outpoint].ptx;
if (!IsNewerThan(*ptxOld))
return false;
for (int i = 0; i < vin.size(); i++)
{
COutPoint outpoint = vin[i].prevout;
if (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx != ptxOld)
return false;
}
break; |
|
|
|
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.
You may be right about this. Bitcoin's segmentation-fixing mechanisms would seem to keep everything in order. A similar feature seems to already be planned. Every transaction has the currently-unused "nLockTime" field, and this bit of code exists for the UI (the text would appear in the same place as "x confirmations"): if (!wtx.IsFinal())
{
if (wtx.nLockTime < 500000000)
return strprintf(_("Open for %d blocks"), nBestHeight - wtx.nLockTime);
else
return strprintf(_("Open until %s"), DateTimeStr(wtx.nLockTime).c_str());
} Sounds very much like what you're thinking of. |
|
|
|
|
That would be useful, but it's probably best to keep scripts stateless. Since different nodes might have different ideas about what the current blockcount is, a situation could develop where half the network considers a transaction valid and half considers it invalid. This is not good for the network.
|
|
|
|
It doesn't even have to be everybody that switches. All that has to happen is that a majority of the CPU power which decides what the next work unit will be will reject mined coins that don't follow the network.
Changing anything that grondilu mentioned ("core parameters") would always split the network. Pre-change peers would never accept post-change blocks or transactions, even if post-change peers have 99% of the network. There would be two networks, though likely both of them would consider themselves to be "the real Bitcoin network". |
|
|
|
Well, bitcoin forks will have to use different names, at least in order to differentiate themselves from the others. I think it wouldn't make much sense to use "bitcoin" for any cryptocurrency other than the one where the total amount is 21 millions, for it has been the name of the original one.
I was referring to the original Bitcoin. If Satoshi removes the halving of block rewards (eliminating the 21 million limit), and everyone switches to that version, then that network is still the real Bitcoin network. |
|
|
|
However, Satoshi is making regular slight modifications to the protocol. Therefore, I think the document lacks a clear and exhaustive list of features that are absolutely necessary to define what bitcoin is.
Such a list could be used to audit the source code and make sure it is compliant to the bitcoin concept.
Amongst those features would be :
* The halfing of bitcoins reward every 210,000 blocks
* use of SHA-256 for hash
* a target of 6 generated blocks per hour
Any of those things can be changed while still remaining Bitcoin. Anything can be changed, really, as long as people using the software still consider its network to be the "real Bitcoin network". The safest "rules" would be the 21 million BTC limit and a responsibility to honor all transactions that have been in the chain for a certain amount of time. Even those might be changed, though. |
|
|
|
|
An orphan block was created at 91405, and I was able to verify that my change to getblock fixes the problem. I suggest that it be included in the patch.
|
|
|
|
But he also suggests future incompatible changes may be integrated via patterns such as
[...]
This has actually been done a few times. The conditional is removed after the "timer has gone off", so you can't easily see the evidence of it. The most recent one was with new transaction limitations: if (nBestHeight > 84000)
{
if (nKeysCount > 20)
return false;
nOpCount += nKeysCount;
if (nOpCount > 201)
return false;
} This limitation on blocks was also phased in recently: // Check that it's not full of nonstandard transactions
if (GetSigOpCount() > MAX_BLOCK_SIGOPS)
return error("CheckBlock() : too many nonstandard transactions"); |
|
|
|
If you mean, how does one audit your addresses with block explorer, simply check the addresses that you have to make sure that there have been no transactions that you didn't do yourself and that the address balances add up to what you should have. If you have more than what you should have, then the website is sharing accounts among users and tracking the individual values internally. Which would allow the website owner to loan out portions of the pooled balance, much like how fractional reserve banks do now, since they don't actually keep your money on hand. If there has been any transactions in or out of said accounts that you didn't perform, then that means the website owner is using member accounts to "float" his own activities.
Bitcoin shares balances among addresses, so you'd have to modify Bitcoin to achieve this separation. |
|
|
|
A "total received by this address" would be cool.
Done. I just noticed a bug, which I won't be able to fix today: the type of transaction listed after "Sent" or "Received" on address pages is wrong.
Fixed. It was actually only "Sent" that was broken. |
|
|
|
Can we get a new graph made that predicts future generation based on past average block intervals, as opposed to the target intervals? I understand that past performance doesn't lead to future performance, but for a while yet it might prove to be a better indicator of the pace of bitcoin generation.
Average blocks per 24 hours for the last x blocks: Last 100: 177.8 Last 200:175.3 Last 400: 201.4 Last 800: 207.2 Last 1600: 222.1 Last 3200: 212.3 Last 6400: 215.5 Last 12800: 194.2 Last 25600: 207.7 Last 51200: 188.6 All time: 134.8 Some graphs using those numbers (x axis is always "days from now"): Last 400 blocks - 201 blocks per day http://img602.imageshack.us/img602/1323/400.pngSubsidy adjustment: June 25, 2012 3200 - 212 blocks per day http://img84.imageshack.us/img84/2149/3200z.pngSubsidy adjustment: May 26, 2012 12800 - 194 blocks per day http://img139.imageshack.us/img139/7711/12800.pngSubsidy adjustment: July 17, 2012 All time - 135 blocks per day http://img691.imageshack.us/img691/3380/alltime.pngSubsidy adjustment: April 10, 2013 |
|
|
|
|
Show Posts
