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

Now why would satoshi do that? Did he know about this inflation bug before it happen? But lets say that RBF had not been disabled by Satoshi. Then do you see the problems that could have occurred? If the same thing happened today, people would be using RBF out the rear end to double spend.

Plus I don't think it's technically necessary to have RBF. For example, a miner can add their new transaction to their mempool and delete the old transaction, mine a block with this new transaction on the new chain. Boom done. not easy but perhaps technically possible.

RBF was disabled by Satoshi in version 0.3.12, eight days prior to the inflation bug. So, no, that would not have worked.

not if i set it up as a RBF.

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.



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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.



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

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.

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.

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.

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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.

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

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