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

[kaggie]

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.

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

[1715241412]

1715241412

[1715241412]

1715241412

[1715241412]

1715241412

[1715241412]

1715241412

[1715241412]

1715241412

[larry_vw_1955]

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

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.

[garlonicon]

Now why would satoshi do that?

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.

Did he know about this inflation bug before it happen?

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.

But lets say that RBF had not been disabled by Satoshi. Then do you see the problems that could have occurred?

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.

Plus I don't think it's technically necessary to have RBF.

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.

not easy but perhaps technically possible

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

[kaggie]

Now why would satoshi do that?

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

As Gavin and I have said clearly before, the software is not at all resistant to DoS attack.  This is one improvement, but there are still more ways to attack than I can count.  

If the same thing happened today, people would be using RBF out the rear end to double spend.

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.

[o_e_l_e_o]

If the same thing happened today, people would be using RBF out the rear end to double spend.

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.

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.

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

[larry_vw_1955]

Now why would satoshi do that?

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.

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.

Plus I don't think it's technically necessary to have RBF.

Of course it is not strictly required. Any transaction with zero confirmations can be always replaced by something else.

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.

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

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-

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.

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.

[o_e_l_e_o]

Satoshi disabled it but then at some point it got re-enabled apparently. Because apparently it is still a thing today.

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.

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.

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.

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

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.

[vjudeu]

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.

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.

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

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.

if you could timestamp transactions then you could just ignore all of them except the one that occurred last

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

So a consensus mechanism would be needed to enforce the correct behavior.

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.

Timestamps need a consensus mechanism if they are going to be useful.

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.

and a replacement with a fee rate of 1000 sats/vbyte

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.

[ABCbits]

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.

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

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.

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

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

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

[larry_vw_1955]

RBF today now has requirements for higher fees which prevents endlessly spamming replacement transactions.

that makes sense.

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.

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.

It doesn't make economic sense why a miner would not act in their best financial interest and accept a replacement that had a larger fee especially if the fee was substantially larger. I think the reason is non-mining nodes won't relay it to them. So they might not even know about the new transaction paying a higher fee. non-mining nodes don't have financial incentive and just go along with the bitcoin source code. miners might have an incentive to modify the code to their economic advantage. so i could see a miner changing the code to let duplicate transaction with larger fee override transaction with smaller one. if i was a miner i would want to be doing that whenever i could so i could make more money.

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

[garlonicon]

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.

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.

[kaggie]

It doesn't make economic sense why a miner would not act in their best financial interest and accept a replacement that had a larger fee especially if the fee was substantially larger. I think the reason is non-mining nodes won't relay it to them. So they might not even know about the new transaction paying a higher fee. non-mining nodes don't have financial incentive and just go along with the bitcoin source code. miners might have an incentive to modify the code to their economic advantage. so i could see a miner changing the code to let duplicate transaction with larger fee override transaction with smaller one. if i was a miner i would want to be doing that whenever i could so i could make more money.

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.

[o_e_l_e_o]

It doesn't make economic sense why a miner would not act in their best financial interest and accept a replacement that had a larger fee especially if the fee was substantially larger.

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.

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.

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.

[larry_vw_1955]

It doesn't make economic sense why a miner would not act in their best financial interest and accept a replacement that had a larger fee especially if the fee was substantially larger.

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.

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

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.

[vjudeu]

So you don't know who they are.

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.

I don't know if the network could just ignore all blocks from a particular pool.

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

Miners and pools are decentralized

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.

they don't have to register with any central authority before they can start mining

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

So you don't know who they are.

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

[ABCbits]

It doesn't make economic sense why a miner would not act in their best financial interest and accept a replacement that had a larger fee especially if the fee was substantially larger.

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.

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.

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.

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.

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.

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

[BlackHatCoiner]

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

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.

But if I told them that I was just trying to speed up the same exact transaction, that's not a double spend.

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

[o_e_l_e_o]

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.

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.

I don't know if the network could just ignore all blocks from a particular pool.

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.

[larry_vw_1955]

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

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.

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.

But if I told them that I was just trying to speed up the same exact transaction, that's not a double spend.

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

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.

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.

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.

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.

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.

[garlonicon]

so I as the sender can't use child pays for parent

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