Pages:
Author

Topic: Why I Do [Not] Want Timestamps Inside Transactions, Reloaded (Part II) - page 3. (Read 653 times)

sr. member
Activity: 333
Merit: 507
Apparently it wasn't very decentralized back then in 2010 since bitcointalk forum served as kind of a hub to tell people to stop generating new blocks so that they could roll back the blockchain and start over from a point before the bad transaction happened. It would be alot harder to control a situation like that now since bitcoin is truly more decentralized, as you say.
It was decentralized, but much less decentralized and popular than now. A network of five people/nodes is decentralized, even if five people is a low number.

Bitcoin was the first major cryptocurrency. That bug was fixed when it had a few hundred thousand dollar market cap and when only a few dozen people knew about bitcoin or crypto in general. And bitcoin has been going strong since...

What about the transactions from 74000 to the invalid block. Are those all invalid now as well?

Only this aberrant transaction and coins generated after it in the block chain will be removed. All other transactions will continue to exist.

Quote from: NewLibertyStandard
Will the bug fix include the 4-way SSE2 patch included in 0.3.9rc2?

It's included.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
This is a continuation of the stand-off occuring at the thread Help a newbie; why is hashing not done once but twice during a Bitcoin transaction about why including timestamps of when the transaction is broadcasted is [or is not] a good idea. Title is general sentiment inside the thread and not my opinion.


Not only would they not shutdown the network, but they can't. They have absolutely no power to do so because bitcoin is decentralized.

Apparently it wasn't very decentralized back then in 2010 since bitcointalk forum served as kind of a hub to tell people to stop generating new blocks so that they could roll back the blockchain and start over from a point before the bad transaction happened. It would be alot harder to control a situation like that now since bitcoin is truly more decentralized, as you say.

Quote
Such a bug has already happened with bitcoin. It is known as the value overflow incident. It happened in 2010, where someone created 184 billion bitcoin out of thin air. You can read about it here: https://bitcointalksearch.org/topic/strange-block-74638-822. Satoshi released a patch to Bitcoin Qt which soft forked the blockchain to undo the bug, but he was powerless to impose it on the network. Instead, we had to rely on nodes choosing to run the new client and then building a chain with enough work to overtake the other chain. That is how decentralized systems work - by consensus of the community, not by one or two people unilaterally deciding to shut down the network.

no one had a choice. that's why they went along with it. otherwise bitcoin would have been destroyed.  but even so, this fix wasn't without its serious issues. people had been sending and receiving bitcoin for about 4 hours until that fix rolled back the blockchain and deleted all their transactions. that's like going to someone's bank account and taking their money back out once it's been deposited and saying "sorry". if that same event happened today instead of 2010, that particular issue would be insanely more serious. how much money is transferred on the bitcoin blockchain in 4 hours? how do you delete that much money from peoples' wallets without a major consequence?


Quote
As pointed out, that does not provide any mechanism for you to trustlessly verify that my timestamps are accurate and not faked.
You don't like timestamps in bitcoin you said it's fine as it is. But look at the link you provided in particular this posting:

https://bitcointalksearch.org/topic/m.10332

This user tried the best he could to put timestamps on all of the events related to this overflow incident. He did the best he could with the data he had but that's proof right there that sometimes you need to know "when" and the more accurately you can know when things happened, the better you can understand it. So timestamps aren't so bad. The more accurate they can be the better.

(I am going to assume that the timestamp referred here is when the transaction is going to be broadcasted)

OK, no big deal about that, just decrease the precision of the timestamp to minutes instead of seconds, so that the signing timestamp and the one in the message don't appear to differ and make the message look rediculous. Humans can't accurately perform events in second-precision anyway.
Pages:
Jump to: