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

ok well i didn't realized about the change. that's pretty clever.

The purpose of doing that could be that you want to send all of your bitcoin to someone. Simple as that. When I say all, I mean all. Not leaving any dust behind. Like for example, you're going all in on an investment and want every milli bitcoin to count.

but back to the main topic of the thread which is distributed timestamping consensus mechanism.

Only if the mempool is very full and if you have paid a very low fee. Which is why I've repeatedly said that if you want to pay using a zero confirmation transaction, then you need to use an appropriate fee. With an appropriate fee the chance of your transaction dropping out of the mempool in two weeks' time and not confirming before then is incredibly low.

And again, as has been explained several times, we are talking about buying a coffee or some fast food. No one is accepting zero confirmations for large values.

Yes you can, using your change output.

You can. A typical transaction has one input and two outputs: one for the seller (as a payment for goods or services), and one for the buyer (as a change). You can always do CPFP on your change (unless you created single-output transaction on purpose, but then, what was the purpose of doing that?).

But don't unconfirmed transactions drop out of the mempool sometimes because they take too long to confirm?  So I'm obligated to resend the same transaction again with a higher fee? Or is that just the risk the merchant is taking? it seems to me that someone that accepts 0-conf transactiions is taking a risk and they can't really go back to the buyer and demand payment again if it doesn't work out for them. Hopefully they didn't sell something like a car. Come to think of it, I think theres a scam based off doing this type of thing to unsuspecting sellers. But a seller that knows about this issue has no excuse if they still choose to accept 0-conf transactions I would think no one is going to feel sorry for them. Just wait until the transaction is in a block or two.

so I as the sender can't use child pays for parent, that is something that has to happen on the receiver's end and they are the one that has to pay the fee. maybe i don't want to have to ask them to do that. and they just want their money. and expect it to work from my end.

i don't see how a merchant could be defrauded in a situation like that. as it's really no different than waiting until the first transaction drops out of the mempool and then resubmitting it with a higher fee. it just makes things go faster maybe if you don't have to wait. but I understand bitcoin in general doesn't distinguish that type of behavior from a malicious double spend attempt. so miners might not like to do it in either case.


as they certainly should.

When Bitcoin turned ten in January 2019, OFAC was barely a month past its first crypto-related enforcement. It was a landmark. Two Bitcoin addresses belonging to Iranian nationals accused of cyber activity against the United States were now on Specially Designated Nationals and Blocked Persons lists (SDN lists), alongside their names, aliases, and emails. All transactions with those addresses are now prohibited.

the day that the us government is able to dictate who gets to spend bitcoin and who doesn't, that is the end of bitcoin. as far as being trustless. it would then be no better than some centralized system like usdc where the "admins" can freeze your account if they want to. the arrogance of the us government has no bounds in regards to thinking they can prohibit bitcoin addresses from transacting. as far as i'm concerned their power should stop at the point where fiat become digital - the bank. but they dont see it that way. they want to try and control not only the usa but every part of the world and impose their will on every part of the world not just inside the borders. which is kind of sad.

Well, if you agree that a miner is going to reject a dishonest double spend, and would only accept a replacement transaction which replicates the original but with a higher fee, then there is a very small chance of a merchant being defrauded and so accepting zero confirmation transactions for low values remains safe.

Entirely possible as vjudeu has explained above. There was already some discussion about such a thing happening in response to some mining pools which started to censor transactions because they involved outputs or addresses that OFAC decided were blacklisted. The pools in question realized that their income and therefore their very existence was at risk and so stopped their censorship.

But, you do try to double-spend money. The fact the transaction isn't included in a block, yet, doesn't make that not true. If somebody had accepted your 0-conf transaction, and you paid a miner to reverse it, you will have essentially gained the chance to spend the money again.

And it is dishonest if you ask me. You've marked your transaction as "non-RBF". This means that, besides your word, a merchant can sleep easy that there won't be nodes that will relay a transaction that double-spends. Reversing that transaction is like cheating the network. If you wanted to have the option to double-spend, you should have opted-in RBF.

If you want to speed up a non-RBF transaction, utilize child-pays-for-parent.

If we're talking about exact/specific transaction without any conflict (which means it's likely exist on miner/pool mempool), such service already exist. ViaBTC already offer such service with both free and paid option.


Some pool use coinbase transaction as identifier of their mined block[1-2]. While anyone could modify Bitcoin Core (or other full node software) to ignore block with certain properties, it's unlikely anyone would agree to do such thing. Besides, pool can evade such restriction easily.

[1] https://mempool.space/block/000000000000000000055b0b48609c6a5db6d59e23d79c6e055f01732c775643
[2] https://mempool.space/tx/2be204049f57dcc4fdbcfd242c941030233333570ae85e70b6d5f4a17681440a

You don't know that in decentralized mining. In centralized pools, you know that, because they are proudly announcing that. They put their name in their coinbase transactions, they also list blocks mined by them on their websites. You cannot be 100% sure about that information, but as long as mining is centralized, most of that messages are true. Of course, any centralized pool could mine some evil blocks anonymously (or pretend to be another pool), but then, they will pass them to their miners, and they will see, what they are mining, and what 80-byte headers they receive. Also, not announcing a block on their website would lower their stats.

So, by checking some centralized websites, and by getting block hashes they announce, it is possible to check only those blocks in the chain, and get some information about the quality of their blocks. If you have a full node, you can compare that with your data, and detect double spends from your perspective. If many nodes will come to the same conclusion, then it is possible to react, and to reach consensus on that.

It is an extreme case. The more realistic scenario would be just announcing that double spends, to let miners and users know about that. Then, they can switch to other pools. When mining will be decentralized, this problem will be solved (and other problems will pop up).

They are not fully decentralized, as long as you cannot get a fraction of the coinbase reward for doing a fraction of needed work. That's why pools were created in the first place. If you have 7 BTC as your coinbase reward (6.25 BTC plus 0.75 BTC in fees), then you could receive 0.00070000 BTC for doing 10,000x less work. As long as you cannot do that in a P2P way, mining is not fully decentralized.

But they do have to register to a centralized mining pool, unless they want to wait years to receive anything.

You don't know the miners. But you can see all centralized mining pools and their centralized websites.

When you use the phrase "double spend" it makes it sound like I'm trying to do something dishonest though. I wouldn't approach them and ask to do a "double spend". That would make me look guilty and their immediate reaction would be to say no. But if I told them that I was just trying to speed up the same exact transaction, that's not a double spend. But if I was changing the transaction in anyway, they might think I was trying to cheat someone out of some money by "double spending" it. that would be like me trying to bribe the mining pool so of course i doubt they would go along with a bribe.

I don't know if the network could just ignore all blocks from a particular pool. Miners and pools are decentralized they don't have to register with any central authority before they can start mining. So you don't know who they are. So if you don't know where a block came from you can't really have anyway to censor blocks from a certain miner or pool.

Feel free to contact a large mining pool directly and ask if they would assist you in performing a double spend, and let them know it would be in their financial interests in doing so as you will pay a much larger fee in the replacement transaction. I would be genuinely interested in hearing what all their responses are. Keep in mind that mining pools have their reputation to consider as well. If it became clear that x pool was repeatedly replacing transactions and facilitating malicious double spends, then there is a good chance that many miners would leave them. At the extreme end, the rest of the network could decide to just ignore all blocks from this malicious pool.

Absolutely. But the things most people are buying and paying for point of sale - coffee, fast food, groceries, etc. - are usually of a small value for which 0 confirmations is acceptable. If you are going to be buying something expensive like a car, then of course you will want to wait for several confirmations, but at the same time, you don't need your transaction to be completed in <10 seconds like you do if you are buying coffee.

The financial incentive is related to trust.

It's not too different from dealing with a salesperson. If he keeps changing the price while you are talking to him, then you half wonder whether he is wasting your time. Or maybe he keeps changing what he says about other things, like whether a particular model is available every other sentence, then you might walk away no matter how good the deal is. A bit like any conversation if you ask me..

If a node sends many different transaction replacements, verifying whether they are all valid are not calculation free, and time is money when you are racing to add the winning block. At some point, ignoring transaction replacements becomes the economic incentive if there are too many transactions that seem like spam.

But you are correct, a miner could choose to allow additional transaction replacements. Individuals on the network would not necessarily know about that miner though to utilize that.

That's why you have a choice, and can decide, how many confirmations you need. I think "coinbase coverage" can be quite good estimate. It means, for every amount lower than the coinbase reward, you need only one confirmation (because reverting that would mean you need to re-do the same work, so it is not worth it). In general, it means that if your coinbase reward is 7 BTC, and you are trying to send 70 BTC, then you can wait 10 blocks, and be quite sure it won't be reversed, because it is no longer worth it.

that makes sense.

OK well if you're buying a cup of coffee yeah but if it's a significant amount of money like exchanges deal with then no way they gonna let you get buy with 0 confirmations.

Feature which disabled by Satoshi usually called "Transaction replacement". RBF is improvement of Transaction replacement which enabled since Bitcoin Core 0.12[1].


Most node won't rely conflicted transaction, so miner would never see 2nd transaction with higher fee on their mempool.


Few business does that under certain condition, there was discussion about accepting 0-conf a year ago[2].

[1] https://bitcoincore.org/en/faq/optin_rbf/
[2] https://bitcointalksearch.org/topic/doubt-about-double-spending-5363009

Satoshi disabled it "for now", you can find that information about "temporary" disabling RBF in his comment. So, enabling it again in a safer way was intended by Satoshi. Because he added that "sequence" field for a reason in the first place.

Now it is true, but in the old times, there was something called "coin age". In the past, fees were calculated in a completely different way.

You can. Just apply your own mempool rules, that will work, and you will still be in the same network.

Accepting and rejecting transactions is node-specific, not consensus-specific. The Core client has some reasonable defaults, but you can change them, or convince other nodes to change them. It is outside of that strict part of "consensus", that makes Bitcoin what it is, just because any node can use any rules, and still stay in the same network. It is possible to create many rules of including and excluding transactions, as long as your transaction will be accepted by any miner with any significant hashrate, you are fine, and Bitcoin is usable for you.

It is enforced on the block level. If you want to enforce it on the transaction level, then you can use locktime. If you want to accept or reject some transaction, based on timestamps, then you can use locktime for that.

There are more limits. There is also a maximum fee rate limit (and as far as I know, this 1000 sats/vbyte is quite close to that). Of course, miners could have no upper limits in their software, but still, those limits are there to avoid mistakes, and to avoid typing amount to send as a fee.

What Satoshi disabled wasn't RBF as we think of it today. Transaction replacement pre-0.3.12 was simply by incrementing the nSequence number as garlonicon has explained, with no limitations or requirements for absolute fees or fee rates which made it open for abuse. RBF today now has requirements for higher fees which prevents endlessly spamming replacement transactions.

Except they won't. The vast majority of nodes will reject any attempted non-RBF double spend, regardless of the fee. You can try this yourself: Broadcast a non-RBF transaction with a fee rate of 1 sat/vbyte, and a replacement with a fee rate of 1000 sats/vbyte. Your replacement will be rejected.

Except they would and they do. I use plenty of merchants which accept zero confirmation transactions if they are non-RBF and pay a reasonable fee. Reversing such a transaction is significantly harder than reversing a credit card transaction, which the vast majority of merchants around the world accept without a second thought.

OK but RBF is still a thing today. Thats what's confusing. Satoshi disabled it but then at some point it got re-enabled apparently. Because apparently it is still a thing today.

that's what i was thinking. if you make the transaction fee high enough, miners will definitely delete the old one and put in the new one. whether it is rbf or not they won't care.

But RBF is still a feature in bitcoin. So I don't think he removed it completely.
https://support.bitpay.com/hc/en-us/articles/360051205632-What-is-RBF-Replace-By-Fee-

Well no one with half a brain would accept a transaction of any type with zero confirmations. Whether it is RBF or not.

To tie this all in to timestamps though, if you could timestamp transactions then you could just ignore all of them except the one that occurred last. And go with it. Without having to bump up the fee. But then miners might not be incentivized as they are with RBF. So a consensus mechanism would be needed to enforce the correct behavior. Timestamps need a consensus mechanism if they are going to be useful. So time needs a consensus mechanism. I think that's the challenge with having timestamps is you have to have a consensus mechanism that exists for time itself. Solana aint it.

Which is why no service in existence accepts RBF transactions with zero confirmations. This has nothing to do with the bug we are discussing and is just a basic fact of how RBF works. RBF transactions are trivial to replace - that's the whole point of them.

Which, again, is entirely separate to this bug. Miners have always been able to do this.

Satoshi removed RBF to make the network more resistant to denial of service attacks.

There have been hard forks of bitcoin, and it is possible to 'double spend' by submitting an unused transaction on the multiple networks by honest individuals that have unspent coin from before the forks.

If there was a major bug found today, then I agree that new bug could be used by dishonest individuals to deprive others of value.

There is not much functional difference to the network between an RBF and submitting multiple transactions. Some, but not much. Handling double spends well is kind of the point of bitcoin.

Because it was possible to misuse that. There are 2^32 possible values in sequence numbers. Imagine starting from zero, and making (2^32)-1 replacements for each transaction. That's why 0xffffffff (-1) is a final transaction, and RBF is 0xfffffffd (-3). If you signal replacement by using -3, then you can go to -2, and later -1 is final. There are two replacements limit. But when you start from 0x00000000, reaching 0xffffffff is a long way, (2^32)-1 replacements can cause too much spam.

I don't think so, because then he could fix it immediately. All amounts are public, so there is no way to use that trick, and remain hidden. It could be hidden in case of Monero, but not here.

Of course. People could spam the network by sending 2^32 versions of each transaction. And that spam could be created, no matter if that inflation bug was fixed or not.

Of course it is not strictly required. Any transaction with zero confirmations can be always replaced by something else. But now, sequence numbers have some consensus meaning they didn't have before, so in case of OP_CHECKSEQUENCEVERIFY it is different.

It is easy, there are commands to include and exclude single transactions, by assigning priorities to each of them. Each node can decide, which transactions will be included, and which transactions will be excluded. Also, each node can sort transactions in any order, as long as there are no dependencies between them. Each node has its own mempool. It is possible to find one node that accepts free transactions, another node that requires one satoshi per virtual byte, another node accepting only 20 satoshis per virtual byte or more, and another node, accepting negative fees, and treating them as "marketplace offers", like "50k sats on input, 100k sats on output, so someone is selling something for 50k, and anyone can add coins to this transaction, because of sighashes".

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?

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.

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.



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