Why I Do [Not] Want Timestamps Inside Transactions, Reloaded (Part II)

[NotATether]

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.

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://bitcointalk.org/index.php?topic=822.0. 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?

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://bitcointalk.org/index.php?topic=822.msg10332#msg10332

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.

[kaggie]

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.

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?

Your serious bug has luckily not happened in bitcoin for 12 years, but bugs are the risk everyone takes when using any cryptocurrency (so why include things like timestamps on every step that can create more bugs?). I don't know why anyone would use any other cryptocurrency because of the potential for serious unknown bugs. At least bitcoin has 12 years of history for running consistently.

If the market cap was a few hundred thousand dollars, the amount of transfers within a day would have been in in the thousands of dollars. That's not that much money. You are correct that if it happened today instead of in 2010, it would be much more serious - but it hasn't for bitcoin, the first and longest running blockchain.

I briefly touched on this:

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...

https://bitcointalk.org/index.php?topic=822.msg10332#msg10332

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.

Four hours after. Timestamps didn't stop the event and it took hours for the bug to be realized and fixed.

Bitcoin timestamps the block so the protocol isn't against timestamps as a whole. The requirement for them to be more accurate would be overly stringent. I have a real issue in that my computer's clock battery is dead, which means that I can't get onto websites to check for the time because my computer's time is too far out after I've booted it. Timestamps are not always better and would likely screw over the less advantaged.

There is also this tidbit about how that bug didn't affect the transactions that had happened, once the network caught up to the bug fix:

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.

Will the bug fix include the 4-way SSE2 patch included in 0.3.9rc2?

It's included.

[o_e_l_e_o]

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.

Just being able to communicate effectively with the community doesn't make bitcoin centralized as long as that community are still free to do whatever they like. If I had a Zoom call set up with a representative from every mining pool in it so I could speak to them all at once, that doesn't make mining centralized. If on the other hand, every mining pool did exactly what I told them without question, then I agree that would be centralized. As I said, Satoshi rolled out a patch, but was powerless to force people to use it - instead enough users chose to run it that their fork eventually became the chain with the most work.

no one had a choice. that's why they went along with it. otherwise bitcoin would have been destroyed.

They absolutely had a choice, and some didn't go along with it initially, which is why it took many hours after the patch for the fork chain to overtake and become the main chain. If there was a significant number of users who didn't agree with the bug patch, they could still be running the other chain to this day. Just because no one chose an option doesn't mean they didn't have the choice.

until that fix rolled back the blockchain and deleted all their transactions.

It didn't. The transactions returned to the mempool and were included in blocks in the new main chain.

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.

Why would having accurate timestamps have made any difference whatsoever to this incident?

[vjudeu]

We have timestamps in transactions. You can always set sequence number to 0xffffffff for all inputs, and then use any locktime. It could be anything, any value will be accepted, even from the far future. But if you want to do simple timestamping, then you can put the current time or the current block number in this field, it would work fine. Also, setting it to any value would allow transaction mining, then you could use it in the same way as nonce is used in block headers, you can change it 2^32 times, and then change your transaction. You can even make some 80-byte transaction, then you can use some ASIC to mine that (but then it would be non-standard, because it would be too small to be standard).

[o_e_l_e_o]

You can always set sequence number to 0xffffffff for all inputs, and then use any locktime. It could be anything, any value will be accepted, even from the far future.

But if you see a new transaction with a locktime of now, you have no way of knowing if I signed it now or if I signed it five years ago and just held on to it (assuming the inputs existed at that time). Similarly, if you see a transaction with a locktime of five years ago, you have no way of knowing if I signed it give years ago or I actually just signed it now and backdated the locktime. It is impossible to verify and trivial to fake, which makes the timestamp therefore meaningless for the purposes larry_vw_1955 was talking about - namely trying to use timestamps to order transactions as a replacement for proof of work.

[kaggie]

namely trying to use timestamps to order transactions as a replacement for proof of work.

Requiring a transaction to occur within moments of signing would also remove features that enable creative methods for inheritance. It would be a step backwards.

[vjudeu]

But if you see a new transaction with a locktime of now, you have no way of knowing if I signed it now or if I signed it five years ago and just held on to it

It's not a bug, it's a feature. Like it or not, we have timestamps in transactions, it is called "locktime", and it means that "this transaction is valid since this time (or since this block)". So if someone do not want timestamps inside transactions, then it is needed to disable locktime entirely to reach that situation. And many transactions has locktime, because it makes it harder to rewrite the history, and it costs no additional on-chain bytes.

assuming the inputs existed at that time

That's the key. Imagine that most clients will put the current time/block in locktime. Then, that chain is protected from some attacks, when you compare that with another chain, where no locktime is enforced.

Similarly, if you see a transaction with a locktime of five years ago, you have no way of knowing if I signed it give years ago or I actually just signed it now and backdated the locktime.

That's also another feature, because after each second and each block, the range of valid locktimes is increasing, and in the future it could reach the point, where any locktime value will be valid, because we will pass 0xffffffff timestamp, and because we will have more than 500,000,000 blocks. So, it is a kind of nonce that keeps increasing, up to reaching 2^32 possible values.

It is impossible to verify and trivial to fake, which makes the timestamp therefore meaningless for the purposes larry_vw_1955 was talking about - namely trying to use timestamps to order transactions as a replacement for proof of work.

It's true. Again: Nothing is Cheaper than Proof of Work. There are two options: people will understand that, or they will be convinced by seeing how each and every "replacement" will be "fixed" by Proof of Work. So far so good, I hope Proof of Work will keep being the best consensus, and I hope it will be possible to always reintroduce it, just to force some people to present something that is really "better", and is not only declared to be better than Proof of Work. To stop that consensus, it is not only needed to show a better idea. It is also needed to have some way of transforming the system permanently, and that's the point where many competing ideas have nothing to offer.

Requiring a transaction to occur within moments of signing would also remove features that enable creative methods for inheritance. It would be a step backwards.

True, but "removing timestamps from transactions" would be also "a step backwards". Maybe I misunderstood it, but the title suggests getting rid of things like locktime, because someone "Do [Not] Want Timestamps Inside Transactions", I read it as "all timestamps, including locktime".

[larry_vw_1955]

They absolutely had a choice, and some didn't go along with it initially, which is why it took many hours after the patch for the fork chain to overtake and become the main chain. If there was a significant number of users who didn't agree with the bug patch, they could still be running the other chain to this day. Just because no one chose an option doesn't mean they didn't have the choice.

the reason they didn't go along with it might be because some of them didn't want to lost their bitcoin, which seems like it could happen. for example, A pays B using bitcoin and gets a product. Blockchain gets reversed. A pays C using the same utxos he used to pay B. B loses his bitcoin.

It didn't. The transactions returned to the mempool and were included in blocks in the new main chain.

I'm not sure about that. The bad block and all blocks after it was deleted completely. And so the new blockchain began brand new from block #74637. So anything that happened after that was completely ignored. That doesn't seem ideal but that's what they seem to have done. Which again, would not go over too well if it happened today. in fact, a different type of fix might be required should something like that happen today which is try and blacklist the address or addresses that got the 184 billion billion bitcoin. But blacklisting isn't a perfect solution. They might just have to live with there being that many extra bitcoins on the blockchain today if it happened.

A better longterm fix seems to be something that checks the amount of bitcoin in existence every single block. And makes that one of the consensus rules that the block is invalid if the # of bitcoin in existence becomes larger than 21,000,000. that way any type of inflation bug would be stopped, not just this particular one but all of them.

Why would having accurate timestamps have made any difference whatsoever to this incident?

i didn't say it would have except that user was just using timestamps to document sequence of events. so they were important in that regard.

[garlonicon]

the reason they didn't go along with it might be because some of them didn't want to lost their bitcoin, which seems like it could happen. for example, A pays B using bitcoin and gets a product. Blockchain gets reversed. A pays C using the same utxos he used to pay B. B loses his bitcoin.

If you mean Value Overflow Incident, then it doesn't work that way. The chain was reorganized once, when it happened, and when coins were worth much less than today. And you can use some client that will be compatible with Bitcoin Core 23.0, and that will allow creating coins out of thin air. The result will be that you will still accept the current chain as the heaviest chain, so you will end up in the same coin. Also, only your node will accept transactions that will create coins out of thin air. You will receive them, you will try to broadcast them, if you will mine a block with any of them, then it would be rejected. So, it was a soft-fork, because you can use the buggy software, and you will end up in the same chain. Backward compatibility goes as far as to the version 0.8.6, but everything is Open Source, so you can reintroduce the same vulnerability in your version forked from 23.0, and you will end up in the same chain.

It didn't. The transactions returned to the mempool and were included in blocks in the new main chain.

I'm not sure about that.

I am sure, because of coinbase maturity. If someone mined a new block, then those coins were fresh. It was needed to wait 120 blocks (in the old times) or 100 blocks (in the current consensus, this value was changed in the past). That means, if you mined a block 74640, then you could spend your coins only in block 74741 (if 100), maybe 74761 (if 120). And we have 6 blocks per hour, that means around 16 hours of waiting (16 hours * 6 blocks/hour = 96 blocks) or more. And everything was fixed in a few hours, like 5 or 6 hours. So I am 99% sure that no coinbase transaction was mined after that Value Overflow Incident, that was mature enough to be spent. So, only coinbase transactions vanished, normal, user-level transactions were just included in a different chain. And the transaction that created coins out of thin air is the only transaction that I know as being rejected. And guess what: 0.50 BTC from that output is still there, untouched even today, check address 17TASsYPbdLrJo3UDxFfCMu5GXmxFwVZSW.

That doesn't seem ideal but that's what they seem to have done.

As long as things are resolved before coinbase transactions reach maturity, it is perfect. If you are a miner, you cannot rely on your coinbase transaction being valid instantly, you have to wait 100 blocks to be sure that no issues were found in the meantime, and that your coins are reorg-safe.

Which again, would not go over too well if it happened today.

It depends on the community. ETH went the way you want, they did that ugly "try and blacklist the address or addresses that got the 184 billion billion bitcoin" by moving coins in a hard-fork way. Bitcoin did it right, ETH did it wrong, and it was so wrong that it splitted into ETH and ETC, just because that community was crazy enough to break their own consensus, and did something against having "unstoppable code".

They might just have to live with there being that many extra bitcoins on the blockchain today if it happened.

It was impossible, because everyone quickly noticed, how to reproduce that bug. Fixing that was the only option, because the bug allowed anyone to produce coins out of thin air. So, Bitcoin had a choice: fix it once and forever, or let it be, and destroy the whole system by not fixing that.

A better longterm fix seems to be something that checks the amount of bitcoin in existence every single block.

It is checked in every single transaction. It is good enough.

And makes that one of the consensus rules that the block is invalid if the # of bitcoin in existence becomes larger than 21,000,000.

It can be hijacked in a soft-fork way, if any Monero-like features will be added, like hiding amounts. Even Monero count amounts by restricting the coinbase, that's good enough, and flexible enough. It should be left as it is.

that way any type of inflation bug would be stopped, not just this particular one but all of them

Not really. Someone could destroy some coins, and create them out of thin air again. So your "fix" is just making things harder, and cannot protect us from all possible inflation bugs. Another thing is that the current consensus will not allow you to reach exactly 21 millions in circulation, so someone could introduce some coins here and there, and still pass your "fix".

i didn't say it would have except that user was just using timestamps to document sequence of events. so they were important in that regard

Just use locktime field for timestamping your transactions. You will quickly see, how it can be faked, and why consensus cannot be based only on that and no Proof of Work.

[kaggie]

A better longterm fix seems to be something that checks the amount of bitcoin in existence every single block. And makes that one of the consensus rules that the block is invalid if the # of bitcoin in existence becomes larger than 21,000,000. that way any type of inflation bug would be stopped, not just this particular one but all of them.

The long term fix for the 2010 bug that you are talking about was relatively simple: the fix was adding a check for negative values and then rejecting those. (I believe also another line checking for the total number of bitcoin was added.) It required a little bit of code logic to handle that well, but that's the essential idea behind the bug/fix.

It didn't. The transactions returned to the mempool and were included in blocks in the new main chain.

I'm not sure about that. The bad block and all blocks after it was deleted completely. And so the new blockchain began brand new from block #74637. So anything that happened after that was completely ignored. That doesn't seem ideal but that's what they seem to have done.

No, not everything was ignored. New blocks were ignored, but all new, post-bug transactions were still valid and are on the current chain, except for the one that used the bug. Even those running the older buggy software without the check eventually had a reorganization that caused the new longest valid chain to take over the older chain after a few days.

the reason they didn't go along with it might be because some of them didn't want to lost their bitcoin, which seems like it could happen.

With the bug they would have lost their bitcoin so that's not the reason. Not updating had nothing to do with lost money or lost bitcoin at that point, but whether they could trust Satoshi or whether they noticed the bug soon enough to update their software before their software updated to the longest chain for them.

[larry_vw_1955]

The long term fix for the 2010 bug that you are talking about was relatively simple: the fix was adding a check for negative values and then rejecting those. (I believe also another line checking for the total number of bitcoin was added.) It required a little bit of code logic to handle that well, but that's the essential idea behind the bug/fix.

Seems like a no-brainer to ensure that the net increase in bitcoin in each block equals the coinbase reward. Just sum up all the inputs and outputs over all transactions. Then subtract and that should equal to the coinbase reward. If not then the supply is being inflated in a wrong way.

No, not everything was ignored. New blocks were ignored, but all new, post-bug transactions were still valid and are on the current chain, except for the one that used the bug. Even those running the older buggy software without the check eventually had a reorganization that caused the new longest valid chain to take over the older chain after a few days.

Well I'm not sure about that. Because it doesn't make sense how you can delete all the blocks past a certain block and how would the bitcoin network know anything about them then. It wouldn't.

[o_e_l_e_o]

Requiring a transaction to occur within moments of signing would also remove features that enable creative methods for inheritance. It would be a step backwards.

As well as other scenarios where transactions are signed in advanced but not broadcast, which includes closing Lightning channels and the escrow set up on some decentralized exchanges.

Maybe I misunderstood it, but the title suggests getting rid of things like locktime, because someone "Do [Not] Want Timestamps Inside Transactions", I read it as "all timestamps, including locktime".

No one was arguing to remove the locktime. If you go back to the original thread linked to by OP, larry_vw_1955 was instead arguing to use timestamps on individual transactions as an ordering mechanism to therefore replace proof of work. As we have pointed out, because a timestamp on a transaction can be trivially faked to any time between the creation of the UTXOs being spent and the current network time/block height, then such timestamps cannot be relied upon to run the entire chain.

Just sum up all the inputs and outputs over all transactions. Then subtract and that should equal to the coinbase reward.[/quote]
Not as simple as that, since there is no requirement for the miner to claim the full coinbase reward, and coins can be sent to unspendable OP_RETURN outputs which are not included in the UTXO set. Still, the bug is now fixed as explained above.

Well I'm not sure about that. Because it doesn't make sense how you can delete all the blocks past a certain block and how would the bitcoin network know anything about them then. It wouldn't.

Because the same thing happens when we have a chain split today. Once all the nodes which were following the discarded chain swap over to the main chain, any transactions which were present in blocks in the discarded chain but not in blocks in the main chain are returned to mempool and mined again.

[PrimeNumber7]

A better longterm fix seems to be something that checks the amount of bitcoin in existence every single block. And makes that one of the consensus rules that the block is invalid if the # of bitcoin in existence becomes larger than 21,000,000. that way any type of inflation bug would be stopped, not just this particular one but all of them.

That solution would not be ideal. If there was some inflation bug that caused the total number of bitcoin today to be 20,999,999.9, under current consensus rules, any block that produced the above would be invalid. Further, the current block reward is currently 6.25BTC, however, the miners do not have to take the full amount (they almost certainly will), and could take less, so using simple algebra to calculate the appropriate number of unspent outputs would break consensus rules. Finally, and probably most importantly, the sum of all unspent outputs is not contained directly in any single block, this means that in order to calculate the sum of all unspent outputs as of block x, you would need to review all blocks leading up to block x, and this is not something that is scalable.

[kaggie]

Just sum up

This is related very, very closely to the error that caused one of the other largest bugs in bitcoin's existence. A developer changed a line in that precise logic. 'Just' is never 'just' so simple. The large negative value in the 2010 bug transaction allowed what's called an overflow error, which broke standard checks and mathematics, which allowed the writing in of any values.

Well I'm not sure about that. Because it doesn't make sense how you can delete all the blocks past a certain block and how would the bitcoin network know anything about them then. It wouldn't.

The blocks were deleted from the mainchain.

The transactions were not deleted yet, especially since the bug was found within a few hours, well before block maturation. The copies of the transactions still existed so they could be reprocessed with the new negative value check.  A bug fix was initially published within about an hour after the bug was found, and Satoshi's fix was published within two hours after. Individuals could update their code at any point, but the official bug fix release was was I would call the next morning. There would be ways to deal with such a bug if it happened long after the transactions were processed, but I'm not sure bitcoin would have survived then if that happened.

The 'network' knows about everything that individuals on the network keep track of, so those deleted blocks could possibly still exist somewhere, possibly. Two chains existed for about a day or two.

[larry_vw_1955]

The transactions were not deleted yet, especially since the bug was found within a few hours, well before block maturation. The copies of the transactions still existed so they could be reprocessed with the new negative value check.  A bug fix was initially published within about an hour after the bug was found, and Satoshi's fix was published within two hours after.

Plenty enough time for someone to resubmit a different transaction to the network using the same utxos with a higher fee so that it would take precendence over the old transaction. I'm surprised nobody did that. They would surely be doing that today if something like that happened. The only reason it didn't happen in this case is bitcoin was small community, bitcoin users was probably oblivious to the issue taking place and never even realized what was happening until it was all fixed. And the people that knew about it had a little bit of integrity to not try and cheat the system.

Individuals could update their code at any point, but the official bug fix release was was I would call the next morning. There would be ways to deal with such a bug if it happened long after the transactions were processed, but I'm not sure bitcoin would have survived then if that happened.

For example, if the hacker would have wanted to, he could have sent off thousands of transactions to other bitcoin addresses, some of them exchanges where he would have exchanged for some other altcoin (maybe those didn't exist then?) and such and such. This would have been much more difficult to reverse. There would be some bag holders. As more interactions occured using those fruadulent bitcoin it would have become more and more difficult to do anything about it. But for some reason he didn't which seems odd unless he was just trying to raise the red flag about this particular bitcoin bug without taking advantage of it. This hacker let bitcoin off easy.

[kaggie]

For example, if the hacker would have wanted to, he could have sent off thousands of transactions to other bitcoin addresses, some of them exchanges where he would have exchanged for some other altcoin (maybe those didn't exist then?) and such and such. This would have been much more difficult to reverse.

There would have required no additional code to reverse bad transactions after the bug fix. Reversals would have been wholly justifiable if they had happened.

Even if those hacked coin had mixed, any later dependent transaction would have been invalid after the bug fix. If they had mixed, they would have been worth being cancelled and would present no meaningful loss. Reversing dependent transactions that could have resulted from the hack, would mean that either the recipients were associated with the hacker, in which case reversing would be justified, or the recipient would want no association with the hacker, in which case reversing would be justified. The value, usage and services of the network were minor at that point, so a loss of a few grand to any individual at max, would be limited to that. Any legitimate crypto today would make a similar decision. A loss to all addresses associated with the hackers transaction at that point, had there been any, would have been much better than the whole network losing all value from proving its inability to be stable and secure.

I do not believe that the hacker was trying to help the network. It seems naive to believe so.

Plenty enough time for someone to resubmit a different transaction to the network using the same utxos with a higher fee so that it would take precendence over the old transaction. I'm surprised nobody did that.

The hack was confirmed into the chain within a few blocks, so that was not enough time to submit a different replace-by-fee transaction to the network.
Also, no one would have the key that initiated the hack transaction, so what you suggest to reverse those transactions would not be possible without a hard fork.
Besides, submitting a different transaction wouldn't accomplish saving the network, and would also implicate whoever did that as a hacker trying to destroy the network. It was much better to simply add in the required logic.

And the people that knew about it had a little bit of integrity to not try and cheat the system.

Integrity or lack thereof would have made little difference. The network was still early, and it was still very much a question of whether bitcoin would survive. There would be no incentive to abuse the bug because successful abuse could have killed the network, and no value would be derived if bitcoin failed.

[larry_vw_1955]

For example, if the hacker would have wanted to, he could have sent off thousands of transactions to other bitcoin addresses, some of them exchanges where he would have exchanged for some other altcoin (maybe those didn't exist then?) and such and such. This would have been much more difficult to reverse.

Reversing dependent transactions that could have resulted from the hack, would mean that either the recipients were associated with the hacker, in which case reversing would be justified, or the recipient would want no association with the hacker, in which case reversing would be justified.

If you say so but i'm not sure everyone would agree. What if the hacker bought some pizzas using his bitcoins? And eats them. You wanna stiff the pizza parlor?

I do not believe that the hacker was trying to help the network. It seems naive to believe so.

It would be naive to think that the hacker - I wouldn't call him a hacker, he clearly had some knowledge of bitcoin core and C++, it would be naive to think that someone like that hadn't thought through the entire sequence of events that would happen once he submitted his faulty transaction. Which is why he didn't even try and move any of his 184 billion billion bitcoins. That was his way of pointing out a bug in bitcoin and having people take it seriously. Which they did. This person was a crypto programming guru. he may have at one time been a contributor to the code base but then had some type of falling out. so he didn't feel like reporting this bug so people could fix it. no he wasn't trying to help the network he was having a little fun by putting it under some pressure. making life difficult but not impossible for the bitcoin project.

[kaggie]

If you say so but i'm not sure everyone would agree. What if the hacker bought some pizzas using his bitcoins? And eats them. You wanna stiff the pizza parlor?

It wasn't possible to buy pizza directly at that point, so no parlor could have been 'stiffed'.

In your scenario that didn't happen, the value of bitcoin would have dropped, and the network possibly would have become disused. So your 'what if' scenario would also stiff the pizza parlor.

so he didn't feel like reporting this bug so people could fix it. no he wasn't trying to help the network he was having a little fun by putting it under some pressure.

That makes no sense. If he wanted people to fix it, then he could have posted the bug to this forum or emailed Satoshi. Satoshi and other developers were responsive, and a simple email would have given them a better chance to respond without the high risk of destroying the project. So no, he was not trying to help the bitcoin network. I don't know why you are trying to justify that person's actions and the effect those actions would have had on pizza parlors.

[o_e_l_e_o]

Plenty enough time for someone to resubmit a different transaction to the network using the same utxos with a higher fee so that it would take precendence over the old transaction.

Which would have been rejected.

Let's say I broadcast Transaction A, which is still unconfirmed when the chain splits due to this hack. I wait for Satoshi to release the patch and a bunch of miners to switch to start working on a new chain. I then broadcast Transaction B to try to replace Transaction A. Transaction A is still in the mempool of this new chain, meaning my new Transaction B would be rejected as a double spend.

In theory, I could wait for the chain to split, broadcast Transaction A to the hacked chain and broadcast a different Transaction B to the new chain, and hope that my intended target 1) is not aware of the split, 2) is viewing the hacked chain rather than the new chain, and 3) will accept few enough confirmations before the hacked chain is replaced. But this particular attack has always existed and still exists today whenever there is a chain split. It is near impossible to pull off and is mitigated by simply waiting for a few more confirmations.

[larry_vw_1955]

Plenty enough time for someone to resubmit a different transaction to the network using the same utxos with a higher fee so that it would take precendence over the old transaction.

Which would have been rejected.

not if i set it up as a RBF.

Let's say I broadcast Transaction A, which is still unconfirmed when the chain splits due to this hack. I wait for Satoshi to release the patch and a bunch of miners to switch to start working on a new chain. I then broadcast Transaction B to try to replace Transaction A. Transaction A is still in the mempool of this new chain, meaning my new Transaction B would be rejected as a double spend.

ok but how do we know transaction A is in the mempool of every node? isn't that a big assumption? not all nodes mempools are identical.

In theory, I could wait for the chain to split, broadcast Transaction A to the hacked chain and broadcast a different Transaction B to the new chain, and hope that my intended target 1) is not aware of the split, 2) is viewing the hacked chain rather than the new chain, and 3) will accept few enough confirmations before the hacked chain is replaced. But this particular attack has always existed and still exists today whenever there is a chain split. It is near impossible to pull off and is mitigated by simply waiting for a few more confirmations.

regarding #3, it took 4 hours to get a fix out the door. so yeah, that's how many confirmations? 24?