Topic: (Ordinals) BRC-20 needs to be removed - page 14. (Read 7771 times)

OK this is just retarded especially the third comment: "I'm the artist who created this project with Peter and can confirm he holds no Bitcoin and likely never will." If he doesn't hold any Bitcoin then who is selling these ordinals? Heck who even owns them  there is no way he's got other people selling this stuff for him and they are not forwarding him at least some of the proceeds (In bitcoin) which means even if he gets it and then sells it on an exchange in a nanosecond, he admits to using Bitcoin.

Even though we've had our disagreements with pooya in the past, I can understand him to an extent. The basic disagreement we've had was that he supported the notion that blockchain must not be used for anything beyond monetary, whereas I supported the notion that as long as you have enough money to waste, any kind of transaction that complies with the rules is acceptable. And --in general-- the monetary incentives and disincentives is what retains the game theory in practice, not arbitrary ethics.

However, it needs to be said that Ordinals could not have brought into existence (at least in that form) without the coincidental removal of the script size limit (which up to this date I feel as if it was not deliberate?).

It could be. But it would require someone to actually put the links together in a convincing manner, ala @zachxbt. I assume with majorly pumped n hyped projects like this there is a degree of wash trading going on, but its all hearsay without actual evidence. Meanwhile whats crazy is the floor price on these things has jumped to 0.73 BTC  

I can't get over the fact that they look like shit. Like, way worse than CryptoPunks.


I think the war you are fighting is inside your head, because nobody else sees this battle but you. Hope your side is winning, for the sake of your own mental wellness.

---

Oh, BTW, this is fun. Peter Schiff has launched his own line of Ordinals, yet he still hates Bitcoin    you literally can't make this stuff up.

It will depend on their HODLers and if there's enough interest from people outside of their community. But it might not last. They're merely HODLing because they're incentivized when the price surges higher. People could ask how is "that" different from Bitcoin. The main difference is Bitcoin is an actual technology that acts as a backer of its ethos. It's no mere dick pick that those users like to keep in their wallets. It's a facilitator that can bring forth actual social and political change.

Considering how we are ~6 years after the ICO scam and it still hasn't died, there is no reason to expect the Ordinals scam and attack end without any intervention. The hype may decrease but wait until market enters big bull run phase and newcomers flood the market, and we'll see how Ordinals Attack increases again as they get fresh victims.

how do you even know all of that is real. maybe most of it is from the same person with different bitcoin addresses.  that's how i think is the recognized way of jumpstarting an nft project is the owner steps in and makes a bunch of fake purchases to get people looking that way. not saying this one in particular but i think alot of people do that. project owners that is. it costs them fees but not much else.

Well, they are/were the ones causing the busy periods. Ordinals activity is down across the board. It appears the hype is finally subsiding; however, last time I said that (in October) it came roaring back with a vengeance, so I don't want to jinx it.

It appears there market has reached an inflection between a saturation point and boredom; there's just too many ordinals + BRC-20 for sale out there and a finite amount of BTC to pay for them. If anyone is interested, this is the collection that seems to be all the rage right now:

https://magiceden.io/ordinals/marketplace/nodemonkes

The floor price is currently >0.4 BTC for them and 45.5 BTC in trading volume over the last 24 hours   insanity. No way it will last.

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?

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:

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

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

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.

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

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.

It is quite recent change. Some older clients, like 22.0, are still affected, and will stay affected. For example: https://bitcointalksearch.org/topic/m.58166985

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.

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?

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

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

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

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.  

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)

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.

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.

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