(Ordinals) BRC-20 needs to be removed

[Wind_FURY]

In the context that there's the Ordinals Chain merge mined with the Bitcoin blockchain, doesn't the miner earn rewards from both chains, and therefore has the choice of which coin to sell to pay for electricity bills/other expenses?

It depends on the sidechain construction. If it is like NameCoin, which created its own tokens, out of thin air, then yes, this is just abusing 21 million coins limit, and then you have separate coins. But you can also have something like RSK, where all coins have 1:1 peg with BTC, and where nothing is created out of thin air.

Does merged mining add extra work for miners

If you mean "can the hashrate increase", then the answer is yes, because those miners are just mining regular Bitcoin blocks.

Edit: If you mean, "does the miner need to choose, which chain to mine", then it is not like that. You simply mine a regular Bitcoin blocks, which are also valid in another network. More than that: you can potentially mine blocks at lower difficulty, which is what P2Pool did (they had blocks every 30 seconds with 20 times lower difficulty, so they had 20 times more blocks, but most of them were present only on P2Pool chain, and other sidechains can use the same trick if they want).

and therefore is like a block size increase?

Not really, unless you make it mandatory for a full node to follow that chain, but then, you need a successful soft-fork to do that. But in case of additional data, there are no new consensus rules behind that. Those data are just huge OP_NOPs, which means, no additional Script needs to be enforced. Which means, there is no need for full nodes to follow that data, and download it. They only stop at verifying signatures, all data behind them are posted separately, and are not processed by full nodes, because it is not needed to determine, if a transaction is valid or not.

OK, then the sidechain would be something like a cheap ledger for Ordinals instead of storing them in a "bank vault", which is the Bitcoin blockchain. Did I understand that right?

I believe that Ordinals' main value proposition is the fact that those dick pics and fart sounds reside in the Bitcoin blockchain. They might lose their perceived value if they're "not an actual part" of Bitcoin.

If there was no incentive to mine the Ordinal Chain, then why try to find blocks there at all?

The incentive is the same as with mining Bitcoin. Which means, you can mine Bitcoin only, or mine Bitcoin, and your own chain, at the same time.

Note that every time, when you create a transaction, you can commit any data into each of your signature, without increasing the size of your transaction.

But from the miners' viewpoint, it's not the same. They're not getting any incentives from the Ordinals sidechain at all, and it would be better for them if Ordinals remain in the Bitcoin blockchain because of the higher fees. Fees which are slowly becoming the main source of miner incentive after every halving.

[vjudeu]

Did I understand that right?

Somewhat, because yes, it would be the case initially. But every sometimes, when someone will need to do a regular Bitcoin payment, then that person will have the chance to confirm the whole sidechain, and to commit to that, so since then, it will be timestamped on Bitcoin.

Which means, there would be several steps:

1. Unconfirmed sidechain transaction.
2. Confirmed on sidechain only.
3. Committed into Bitcoin (with zero additional on-chain bytes, along with all pending commitments).

They might lose their perceived value if they're "not an actual part" of Bitcoin.

They will lose it anyway, if they will abuse nodes more than today, because then, people will have an incentive to apply "Reclaim Disk Space" from the whitepaper, also to the Initial Blockchain Download.

They're not getting any incentives from the Ordinals sidechain at all

They could "own" some Ordinals, by confirming those "tokens". Even more than that: it is possible to make a system, where mining could be the only way to create new Ordinal.

and it would be better for them if Ordinals remain in the Bitcoin blockchain because of the higher fees

There are better ways than Ordinals to increase fees.

[Siyamsk]

In the context that there's the Ordinals Chain merge mined with the Bitcoin blockchain, doesn't the miner earn rewards from both chains, and therefore has the choice of which coin to sell to pay for electricity bills/other expenses?

It depends on the side chain construction. If it is like Name Coin, which created its own tokens, out of thin air, then yes, this is just abusing 21 million coins limit, and then you have separate coins. But you can also have something like RSK, where all coins have 1:1 peg with BTC, and where nothing is created out of thin air.

Ok I understand it depends on the side chain construction.  But how to create your own tokens out of thin air?  How was the upuse of 21 million tokens and what are their benefits?

If you mean "can the hashrate increase", then the answer is yes, because those miners are just mining regular Bitcoin blocks.
Edit: If you mean, "does the miner need to choose, which chain to mine", then it is not like that. You simply mine a regular Bitcoin blocks, which are also valid in another network. More than that: you can potentially mine blocks at lower difficulty, which is what P2Pool did (they had blocks every 30 seconds with 20 times lower difficulty, so they had 20 times more blocks, but most of them were present only on P2Pool chain, and other sidechains can use the same trick if they want).

Yes you are right that mining bitcoin blocks requires something readily available.  It is valid through other networks.  And it's the only P2Pool that can or has done that.

[vjudeu]

But how to create your own tokens out of thin air?

It is very easy. For example, you can just start regtest, and then you can print a lot of "monopoly money". And if you disable the halving, then you can have unlimited money, created out of thin air. Or you can just lift the protection from Value Overflow Incident, and then use that overflow bug, to produce as many coins as you want.

How was the upuse of 21 million tokens and what are their benefits?

It doesn't matter if it is 21 million. What matters most, is that the amount is finite, so it doesn't lose value like fiat currencies. But of course, there are many altcoins, producing coins like crazy, and they can also be successful, because people are used to fiat-like systems, and they are also used to pump-and-dump speculation.

And it's the only P2Pool that can or has done that.

Anyone can do that. You can start even from regtest difficulty, if you want, and just let it adjust to your network. Which means, instead of making separate chain for any test network, it is possible to mine valid Bitcoin blocks at the same time. And I wonder, why for example signet or testnet3 is not designed like that. Because it is technically possible, and by checking the chainwork of some networks, I can see for example some testnet3 miners, producing a valid mainnet block from time to time.

[tromp]

It doesn't matter if it is 21 million. What matters most, is that the amount is finite, so it doesn't lose value like fiat currencies.

It doesn't matter if it's finite. Quoting from [1]:

It doesn’t take much to change a finite supply into an infinite one. Bitcoin’s block reward drops from 1 satoshi to 0 satoshi somewhere in the year 2140, completing a supply of approximately 21 million bitcoin. What if that final drop never happened?

Bitcoin would continue emitting a 1 satoshi block reward in perpetuity, yielding an infinite supply. It would eventually reach 21 million + 1 bitcoin. Let’s see when that happens. We need to wait an additional 100 million blocks, which takes approximately 10⁸/6/24/365 = 1902 years.

Would that make make Bitcoin any less hard a currency? I don’t think anyone would be willing to argue that. So what makes a currency hard, if not a capped supply? I think the answer is obvious. Eventual negligible inflation is what makes for hard currency. It is what distinguishes cryptocurrencies from fiat.

[1] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153

[cryptosize]

https://bitcointalk.org/index.php?topic=5480574.msg63454673#msg63454673

Thoughts?

[vjudeu]

What if that final drop never happened?

It would be backward-incompatible.

Bitcoin would continue emitting a 1 satoshi block reward in perpetuity, yielding an infinite supply.

And all of those blocks would be ignored by old nodes.

Would that make make Bitcoin any less hard a currency?

Yes, because if you follow some invalid chain, then you can no longer be sure, that other rules are not broken as well. There are many things, which can be used to trick SPV nodes, which will not be followed by full nodes.

So what makes a currency hard, if not a capped supply?

You don't need an infinite supply, to do what you want to do. Just change the proportions. Instead of producing additional coins, just make a consensus rule to take single satoshis from users. Then, it will be a soft-fork. For example: if for each transaction, it would be mandatory to send 100% coins as fees, it would be a valid soft-fork. Because it is all about proportions, and not about having 21 million coins in particular.

Eventual negligible inflation is what makes for hard currency.

The current inflation is not "negligible", if you count, how many altcoins are there. And almost all of them can be used, to bypass 21 million coins limit. Which also means, that we already have enough coins. And burning them is quite popular on many chains, not because there are not enough coins, but rather because they produced too much earlier.

[tromp]

What if that final drop never happened?

It would be backward-incompatible.

The article considers a hypothetical alternate design that Satoshi could have chosen.
It does not propose any change to the existing design.

In fact, I consider any proposal of a tail emission for bitcoin to be a non-starter, as the 21M cap and immutability are the core essence of Bitcoin.

[larry_vw_1955]

In fact, I consider any proposal of a tail emission for bitcoin to be a non-starter, as the 21M cap and immutability are the core essence of Bitcoin.

I don't see how anyone could argue that bitcoin is "immutable". In what sense is it immutable? If we have developers that can modify bitcoin and put in new things like taproot, I don't see how anyone can consider it immutable.

The 21M hardcap has remained unmolested luckily. So, so far, that part has been immutable...

[vjudeu]

In what sense is it immutable?

Because you can change the code, but you cannot force the people to run your version. Which means, that if for example Bitcoin Core developers would try to do a hard-fork, and increase the amount of coins directly, just by using bigger numbers, then that would be strictly rejected by old nodes. And then, people could simply refuse to upgrade.

Note that there are many altcoins, where full nodes are just left unupgraded, and where people just use some old version for many years. Which means, that stopping upgrades, and forming another group of developers is possible, if people will stop trusting the current group. And for that reason, Bitcoin Core developers don't want to create hard-forks. They could simply lose control over Bitcoin, if they would do so, and include some controversial changes.

If we have developers that can modify bitcoin and put in new things like taproot, I don't see how anyone can consider it immutable.

But Taproot is compatible with old versions. In the past, there were some hard-forks, when the community was small, and when people put less money into the system. But as it grew, it became harder and harder to change things. If you want to do something like Segwit or Taproot, you have to contact with mining pools. Because if you don't, then those coins could be simply sweeped by any mining pool, just because they are spendable in the old version.

In case of altcoins, they can do a lot of hard-forks, because those coins are centralized, and often "immature". Which means, that developers can say "please upgrade", and simply say "if you don't upgrade, you are no longer using our coin". But in Bitcoin, that approach wouldn't work, because then, more conservative users would say "it is decentralized, and I will not upgrade, because you just created an altcoin". And what those developers would do then, if the economic majority would not follow their code?

So far, it turned out that many issues can be solved without any hard-fork. But I wonder, what will happen in 2038 or 2106. Because those two dates could cause 32-bit timestamp overflow, and some nodes could crash, so any "upgrade" would mean "hard-fork" from their perspective. But we will see.

[cryptosize]

So far, it turned out that many issues can be solved without any hard-fork. But I wonder, what will happen in 2038 or 2106. Because those two dates could cause 32-bit timestamp overflow, and some nodes could crash, so any "upgrade" would mean "hard-fork" from their perspective. But we will see.

So the earliest hard fork should happen around 2038?

And what's the motive behind 32-bit timestamps? Did Satoshi want Bitcoin to be compatible with 32-bit x86 CPUs? (could make sense back in 2009, not so much anymore)

[DooMAD]

I don't see how anyone could argue that bitcoin is "immutable". In what sense is it immutable? If we have developers that can modify bitcoin and put in new things like taproot, I don't see how anyone can consider it immutable.

The 21M hardcap has remained unmolested luckily. So, so far, that part has been immutable...

The past blocks in the blockchain are immutable.  Not the protocol.  No one can change the transaction history or who owns what sum of BTC without forking themselves off the network where they can't do any damage.

Certain aspects of the protocol could perhaps be described as "ossified" and very difficult to change.  

[vjudeu]

So the earliest hard fork should happen around 2038?

It shouldn't. But it may be the case. You can run your full node, and switch your system clock for example to 2040 or 2110. If your node will crash, or will stop accepting new blocks (for example in regtest mode), then you are affected. If it will keep producing new blocks, then it works as intended. So, instead of trusting me, you can just run it offline in regtest mode, and figure it out directly, on your computer (and because of regtest, you don't have to download existing chain).

And what's the motive behind 32-bit timestamps?

This is the size of the timestamp field in block headers. The 2038 year problem may happen, because it is converted between signed and unsigned integers. The 2106 year problem will happen, because then all 32 bits will be exhausted, and it will overflow into zero again. And yes, it can be solved for example by using time modulo 2^32 (because 136 years time accuracy is more than enough for 10 minute intervals), but even that simple change would mean, that old nodes could simply crash, or refuse to accept new blocks, and from their perspective, the chain will simply halt (which means, that users will have to upgrade, but it is hard to guess, to which version they would like to update).

Did Satoshi want Bitcoin to be compatible with 32-bit x86 CPUs?

Well, it is just a design mistake. Amount of coins use 64-bit values. So it was possible even then, to implement that differently, or to even use something like VarInt, to make it forward-compatible. Or, even better: it could be just VarInt, relative to the previous block. But it is what it is, and we have to deal with that somehow in the future.

Edit: If the size of the timestamp would be 8 bytes, instead of 4, then the size of the whole header would be 84 bytes, instead of 80 bytes. And note, how conveniently it is 84=21*4, so people could see the magic number "21" again (and also, it would be historically correct, because Satoshi changed coin supply from 20 millions in pre-release version, into 21 millions in the current one, by switching from 15 minutes block time, 100k blocks per halving, 30 days difficulty adjustment, and 100 BTC reward, into what we have today).

[mikeywith]

So the earliest hard fork should happen around 2038?

It shouldn't. But it may be the case. You can run your full node, and switch your system clock for example to 2040 or 2110. If your node will crash, or will stop accepting new blocks (for example in regtest mode), then you are affected. If it will keep producing new blocks, then it works as intended.

I believe this test is inaccurate, setting your clock forward into the future would not affect how your node verifies new blocks since all those blocks are still in the current time,  however, if you use getblocktemplate to create a new block with nTime = 4419702898 which corresponds to Monday, January 20, 2110 11:14:58 PM and is 33 bits, other nodes will reject your block.

Setting it to 2040 would also fail but not because of the UNIX time since nTime in block.f is declared as unsigned int which won't overflow post-year 2038, but because the block timestamp will be greater than 2 hours of the median time from the network-adjusted time, but then you may go around this by broadcasting the block to another node you have after changeing the MAX_FUTURE_BLOCK_TIME to some large value that would make a 2040 block valid.

Pull #26259 contains a test for 2106 block timestamps, have you tried it?

[vjudeu]

since all those blocks are still in the current time

Note that regtest has no chain, it is produced from scratch. Which means, that you are the one producing blocks, and you can use any timestamps you want, because they are taken from your system time. So, if you change your system clock, then you will get different timestamps in the blocks you produce.

to create a new block with nTime = 4419702898

I don't know, how do you want to fit that number into 32-bit variable.

but because the block timestamp will be greater than 2 hours of the median time from the network-adjusted time

In regtest, you can use any timestamps you want. I successfully set my clock into 2012, and produced 200k blocks in regtest. It has minimal difficulty, and can be done on every CPU.

Pull #26259 contains a test for 2106 block timestamps, have you tried it?

It is quite recent change. Some older clients, like 22.0, are still affected, and will stay affected. For example: https://bitcointalk.org/index.php?topic=5365359.msg58166985#msg58166985

Which means, that the oldest compatible version, will no longer be 0.8.6 or something, but rather something above 22.0. Which means, for all older clients, it will be a hard-fork. But of course, if enough versions will be used in between, then it wouldn't be a problem, if most nodes will have today's version or later, in 2038. Which means, in 2038, it may be a problem, but it shouldn't be. And 2106 problem is worse, because then, tricks like "time modulo 2^32" are needed, or something like that.

[Learn Bitcoin]

Do you guys know Luke Dashjr? A prominent Bitcoin developer. He always opposed the idea of BRC-20 and I recently saw an article on CoinmarketCap about it. It was written a month ago but I only read that a few days ago.

Luke Dashjr, founder and CTO of OCEAN mining pool, claimed that inscriptions used by Ordinals and BRC-20 creators to embed data on satoshis are “exploiting a vulnerability” in the Bitcoin Core network, resulting in "spamming the blockchain."

Dashjr explained that the Bitcoin Core code has allowed users to set limits on the size of extra data in transactions since 2013, but inscriptions bypass this limit by obfuscating their data as program code.

The bug that allows inscriptions to bypass this limit was recently fixed in the latest update to Bitcoin Knots, a derivative of Bitcoin Core ^[1]

If this happens in the next update, These Ordinals NFT holders will be fucked up. Most importantly, Bitcoiners will get a life.

[1] Bug Fix on Bitcoin Core Could End Bitcoin Ordinals and BRC-20 Token, According to Bitcoin Developer

[nutildah]

This has been brought up a few times in this thread already. Inscriptions don't "obfuscate" anything. It is data that is stored in the witness field of a transaction and decoded by external protocols. Bitcoin Knots is a little-used implementation of Bitcoin software designed by Luke. As of right now, there are ~64 nodes running Bitcoin Knots, as opposed to ~16,979 nodes running Bitcoin Core.

For the most part, Luke holds no sway over major changes to Bitcoin Core, and his request to "fix the bug" will be ignored. Bitcoin Knots can do all the updates it wants. It won't affect Ordinals in any way whatsoever.

[larry_vw_1955]

For the most part, Luke holds no sway over major changes to Bitcoin Core, and his request to "fix the bug" will be ignored. Bitcoin Knots can do all the updates it wants. It won't affect Ordinals in any way whatsoever.

Not only that but a miner who runs Bitcoin Knots is just hurting themself since they lose out on a larger mempool. Reducing the transaction fees they can earn. So I doubt any miner would use something so restrictive.

[nutildah]

For the most part, Luke holds no sway over major changes to Bitcoin Core, and his request to "fix the bug" will be ignored. Bitcoin Knots can do all the updates it wants. It won't affect Ordinals in any way whatsoever.

Not only that but a miner who runs Bitcoin Knots is just hurting themself since they lose out on a larger mempool. Reducing the transaction fees they can earn. So I doubt any miner would use something so restrictive.

This is true. It's an ideological-based decision to run Knots or participate in Luke's mining pool. The irony is Luke has been putting bible verses in mined blocks since 2011. At the time, he was also accused of "polluting the blockchain with nonsense." This, among other weird reasons, are why its hard to take him seriously.

Apparently his new pool, Ocean, has mined a whole 17 blocks since coming back late November, which is actually more than I thought they would. You can see on this page see which transactions their block template rejects from a block, kind of interesting:

[joker_josue]

This low fee face has been good.
But, I wonder why the Ordinals guys aren't making their moves now.
Why are you only interested in doing this during busy periods?